Business Agility – Page 2 – PM Power Consulting

So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n

I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Changes that would help customers to\nmove their business forward (Innovative trends)<\/li>\n<\/ol>\n\n\n\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Changes that would reduce the cost\nof running the business \u2013 i.e., cost of ownership<\/li>\n\n\n\n
Changes that would help customers to\nmove their business forward (Innovative trends)<\/li>\n<\/ol>\n\n\n\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
\n
Changes that would reduce the cost\nof running the business \u2013 i.e., cost of ownership<\/li>\n\n\n\n
Changes that would help customers to\nmove their business forward (Innovative trends)<\/li>\n<\/ol>\n\n\n\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
This perspective\ngives a business software product vendor a new way of looking at their innovations:<\/p>\n\n\n\n
\n
Changes that would reduce the cost\nof running the business \u2013 i.e., cost of ownership<\/li>\n\n\n\n
Changes that would help customers to\nmove their business forward (Innovative trends)<\/li>\n<\/ol>\n\n\n\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Most businesses\nwould like to minimize the cost of keeping the business running and spend more\non moving the business forward. Software product license renewals are typically\npart of \u2018keeping the business running\u2019. New solutions that would help businesses\ncompete and win in the future would fall into the category of \u2018Move business\nforward\u2019. I would call these real \u2018Innovations\u2019.<\/p>\n\n\n\n
This perspective\ngives a business software product vendor a new way of looking at their innovations:<\/p>\n\n\n\n
\n
Changes that would reduce the cost\nof running the business \u2013 i.e., cost of ownership<\/li>\n\n\n\n
Changes that would help customers to\nmove their business forward (Innovative trends)<\/li>\n<\/ol>\n\n\n\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
$\"\"$ <\/p>\n\n\n\n
Most businesses\nwould like to minimize the cost of keeping the business running and spend more\non moving the business forward. Software product license renewals are typically\npart of \u2018keeping the business running\u2019. New solutions that would help businesses\ncompete and win in the future would fall into the category of \u2018Move business\nforward\u2019. I would call these real \u2018Innovations\u2019.<\/p>\n\n\n\n
This perspective\ngives a business software product vendor a new way of looking at their innovations:<\/p>\n\n\n\n
\n
Changes that would reduce the cost\nof running the business \u2013 i.e., cost of ownership<\/li>\n\n\n\n
Changes that would help customers to\nmove their business forward (Innovative trends)<\/li>\n<\/ol>\n\n\n\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
I started wondering \u2018How would a customer of such a business software perceive value or innovation?\u2019. In general, value is defined as some feature that solves a business problem for a user. That is a meaningful definition from a user perspective. What if I wear a CIO hat? I recalled my days as the head of an IT function a few years back. Although times have changed quite a bit since then, I believe, fundamentals of IT spend decisions have not changed. Here is a perspective on how Business-IT steering committee would look at the spend:<\/p>\n\n\n\n
$\"\"$ <\/p>\n\n\n\n
Most businesses\nwould like to minimize the cost of keeping the business running and spend more\non moving the business forward. Software product license renewals are typically\npart of \u2018keeping the business running\u2019. New solutions that would help businesses\ncompete and win in the future would fall into the category of \u2018Move business\nforward\u2019. I would call these real \u2018Innovations\u2019.<\/p>\n\n\n\n
This perspective\ngives a business software product vendor a new way of looking at their innovations:<\/p>\n\n\n\n
\n
Changes that would reduce the cost\nof running the business \u2013 i.e., cost of ownership<\/li>\n\n\n\n
Changes that would help customers to\nmove their business forward (Innovative trends)<\/li>\n<\/ol>\n\n\n\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
In my\nopinion, one of the most overused words in the software industry is \u2018innovation\u2019.\nI understand there is a wide spectrum of enhancements that can be called \u2018innovations\u2019\n\u2013 minor enhancement that improves a business process to a module that supports\na new business process to a new application that is disruptive. Here is what I\nhave observed in software product companies that create business solutions for a\nlarge customer base \u2013 anything other than their customer support issues is called\nan innovation. These \u2018innovations\u2019 require new funding approvals within the product\norganization \u2013 usually supported by robust prioritization processes aligned to strategic\nthemes. All these innovations are expected to represent \u2018value\u2019 for the customer\nand are expected to drive software subscription and license-based revenue.<\/p>\n\n\n\n
I started wondering \u2018How would a customer of such a business software perceive value or innovation?\u2019. In general, value is defined as some feature that solves a business problem for a user. That is a meaningful definition from a user perspective. What if I wear a CIO hat? I recalled my days as the head of an IT function a few years back. Although times have changed quite a bit since then, I believe, fundamentals of IT spend decisions have not changed. Here is a perspective on how Business-IT steering committee would look at the spend:<\/p>\n\n\n\n
$\"\"$ <\/p>\n\n\n\n
Most businesses\nwould like to minimize the cost of keeping the business running and spend more\non moving the business forward. Software product license renewals are typically\npart of \u2018keeping the business running\u2019. New solutions that would help businesses\ncompete and win in the future would fall into the category of \u2018Move business\nforward\u2019. I would call these real \u2018Innovations\u2019.<\/p>\n\n\n\n
This perspective\ngives a business software product vendor a new way of looking at their innovations:<\/p>\n\n\n\n
\n
Changes that would reduce the cost\nof running the business \u2013 i.e., cost of ownership<\/li>\n\n\n\n
Changes that would help customers to\nmove their business forward (Innovative trends)<\/li>\n<\/ol>\n\n\n\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Bill has a difficult task on his hands \u2013 the backlog is his baby. He needs to take a hard and objective look at the existing backlog and find ways to cherry pick items in the existing backlog that align with the new strategy of the board to focus on market trends. Rest of the items should be dropped from the backlog. He would then be able to have a meaningful conversation with John to blend the consultant\u2019s industry analysis and his own understanding of the customer base. A new prioritized backlog would then emerge that is aligned to strategic intent without sabotaging the existing customer base. <\/p>\n","post_title":"CHOW #296: Backlog Blinkers","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-296-backlog-blinkers","to_ping":"","pinged":"","post_modified":"2024-01-24 11:01:36","post_modified_gmt":"2024-01-24 11:01:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20012","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20008,"post_author":"7","post_date":"2022-05-29 17:41:22","post_date_gmt":"2022-05-29 12:11:22","post_content":"\n
In my\nopinion, one of the most overused words in the software industry is \u2018innovation\u2019.\nI understand there is a wide spectrum of enhancements that can be called \u2018innovations\u2019\n\u2013 minor enhancement that improves a business process to a module that supports\na new business process to a new application that is disruptive. Here is what I\nhave observed in software product companies that create business solutions for a\nlarge customer base \u2013 anything other than their customer support issues is called\nan innovation. These \u2018innovations\u2019 require new funding approvals within the product\norganization \u2013 usually supported by robust prioritization processes aligned to strategic\nthemes. All these innovations are expected to represent \u2018value\u2019 for the customer\nand are expected to drive software subscription and license-based revenue.<\/p>\n\n\n\n
I started wondering \u2018How would a customer of such a business software perceive value or innovation?\u2019. In general, value is defined as some feature that solves a business problem for a user. That is a meaningful definition from a user perspective. What if I wear a CIO hat? I recalled my days as the head of an IT function a few years back. Although times have changed quite a bit since then, I believe, fundamentals of IT spend decisions have not changed. Here is a perspective on how Business-IT steering committee would look at the spend:<\/p>\n\n\n\n
$\"\"$ <\/p>\n\n\n\n
Most businesses\nwould like to minimize the cost of keeping the business running and spend more\non moving the business forward. Software product license renewals are typically\npart of \u2018keeping the business running\u2019. New solutions that would help businesses\ncompete and win in the future would fall into the category of \u2018Move business\nforward\u2019. I would call these real \u2018Innovations\u2019.<\/p>\n\n\n\n
This perspective\ngives a business software product vendor a new way of looking at their innovations:<\/p>\n\n\n\n
\n
Changes that would reduce the cost\nof running the business \u2013 i.e., cost of ownership<\/li>\n\n\n\n
Changes that would help customers to\nmove their business forward (Innovative trends)<\/li>\n<\/ol>\n\n\n\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Suggested solution:<\/strong><\/p>\n\n\n\n
Bill has a difficult task on his hands \u2013 the backlog is his baby. He needs to take a hard and objective look at the existing backlog and find ways to cherry pick items in the existing backlog that align with the new strategy of the board to focus on market trends. Rest of the items should be dropped from the backlog. He would then be able to have a meaningful conversation with John to blend the consultant\u2019s industry analysis and his own understanding of the customer base. A new prioritized backlog would then emerge that is aligned to strategic intent without sabotaging the existing customer base. <\/p>\n","post_title":"CHOW #296: Backlog Blinkers","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-296-backlog-blinkers","to_ping":"","pinged":"","post_modified":"2024-01-24 11:01:36","post_modified_gmt":"2024-01-24 11:01:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20012","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20008,"post_author":"7","post_date":"2022-05-29 17:41:22","post_date_gmt":"2022-05-29 12:11:22","post_content":"\n
In my\nopinion, one of the most overused words in the software industry is \u2018innovation\u2019.\nI understand there is a wide spectrum of enhancements that can be called \u2018innovations\u2019\n\u2013 minor enhancement that improves a business process to a module that supports\na new business process to a new application that is disruptive. Here is what I\nhave observed in software product companies that create business solutions for a\nlarge customer base \u2013 anything other than their customer support issues is called\nan innovation. These \u2018innovations\u2019 require new funding approvals within the product\norganization \u2013 usually supported by robust prioritization processes aligned to strategic\nthemes. All these innovations are expected to represent \u2018value\u2019 for the customer\nand are expected to drive software subscription and license-based revenue.<\/p>\n\n\n\n
I started wondering \u2018How would a customer of such a business software perceive value or innovation?\u2019. In general, value is defined as some feature that solves a business problem for a user. That is a meaningful definition from a user perspective. What if I wear a CIO hat? I recalled my days as the head of an IT function a few years back. Although times have changed quite a bit since then, I believe, fundamentals of IT spend decisions have not changed. Here is a perspective on how Business-IT steering committee would look at the spend:<\/p>\n\n\n\n
$\"\"$ <\/p>\n\n\n\n
Most businesses\nwould like to minimize the cost of keeping the business running and spend more\non moving the business forward. Software product license renewals are typically\npart of \u2018keeping the business running\u2019. New solutions that would help businesses\ncompete and win in the future would fall into the category of \u2018Move business\nforward\u2019. I would call these real \u2018Innovations\u2019.<\/p>\n\n\n\n
This perspective\ngives a business software product vendor a new way of looking at their innovations:<\/p>\n\n\n\n
\n
Changes that would reduce the cost\nof running the business \u2013 i.e., cost of ownership<\/li>\n\n\n\n
Changes that would help customers to\nmove their business forward (Innovative trends)<\/li>\n<\/ol>\n\n\n\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
What would be your advice to Bill?<\/p>\n\n\n\n
Suggested solution:<\/strong><\/p>\n\n\n\n
Bill has a difficult task on his hands \u2013 the backlog is his baby. He needs to take a hard and objective look at the existing backlog and find ways to cherry pick items in the existing backlog that align with the new strategy of the board to focus on market trends. Rest of the items should be dropped from the backlog. He would then be able to have a meaningful conversation with John to blend the consultant\u2019s industry analysis and his own understanding of the customer base. A new prioritized backlog would then emerge that is aligned to strategic intent without sabotaging the existing customer base. <\/p>\n","post_title":"CHOW #296: Backlog Blinkers","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-296-backlog-blinkers","to_ping":"","pinged":"","post_modified":"2024-01-24 11:01:36","post_modified_gmt":"2024-01-24 11:01:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20012","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20008,"post_author":"7","post_date":"2022-05-29 17:41:22","post_date_gmt":"2022-05-29 12:11:22","post_content":"\n
In my\nopinion, one of the most overused words in the software industry is \u2018innovation\u2019.\nI understand there is a wide spectrum of enhancements that can be called \u2018innovations\u2019\n\u2013 minor enhancement that improves a business process to a module that supports\na new business process to a new application that is disruptive. Here is what I\nhave observed in software product companies that create business solutions for a\nlarge customer base \u2013 anything other than their customer support issues is called\nan innovation. These \u2018innovations\u2019 require new funding approvals within the product\norganization \u2013 usually supported by robust prioritization processes aligned to strategic\nthemes. All these innovations are expected to represent \u2018value\u2019 for the customer\nand are expected to drive software subscription and license-based revenue.<\/p>\n\n\n\n
I started wondering \u2018How would a customer of such a business software perceive value or innovation?\u2019. In general, value is defined as some feature that solves a business problem for a user. That is a meaningful definition from a user perspective. What if I wear a CIO hat? I recalled my days as the head of an IT function a few years back. Although times have changed quite a bit since then, I believe, fundamentals of IT spend decisions have not changed. Here is a perspective on how Business-IT steering committee would look at the spend:<\/p>\n\n\n\n
$\"\"$ <\/p>\n\n\n\n
Most businesses\nwould like to minimize the cost of keeping the business running and spend more\non moving the business forward. Software product license renewals are typically\npart of \u2018keeping the business running\u2019. New solutions that would help businesses\ncompete and win in the future would fall into the category of \u2018Move business\nforward\u2019. I would call these real \u2018Innovations\u2019.<\/p>\n\n\n\n
This perspective\ngives a business software product vendor a new way of looking at their innovations:<\/p>\n\n\n\n
\n
Changes that would reduce the cost\nof running the business \u2013 i.e., cost of ownership<\/li>\n\n\n\n
Changes that would help customers to\nmove their business forward (Innovative trends)<\/li>\n<\/ol>\n\n\n\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
John, the\nnew CEO, had come from a new-age software company. He proposed several new\ninnovations based on the industry trend analysis by the management consulting\nfirm hired by the board. When he spoke to Bill, he realized that there is a 3-year\nbacklog of work already planned and published to the customer base in the form\nof product roadmap. Bill was really concerned about disappointing the customer\nbase if the current roadmap is not realized. John had the support of the board\nand he directed Bill to find way to prioritize the new innovations.<\/p>\n\n\n\n
What would be your advice to Bill?<\/p>\n\n\n\n
Suggested solution:<\/strong><\/p>\n\n\n\n
Bill has a difficult task on his hands \u2013 the backlog is his baby. He needs to take a hard and objective look at the existing backlog and find ways to cherry pick items in the existing backlog that align with the new strategy of the board to focus on market trends. Rest of the items should be dropped from the backlog. He would then be able to have a meaningful conversation with John to blend the consultant\u2019s industry analysis and his own understanding of the customer base. A new prioritized backlog would then emerge that is aligned to strategic intent without sabotaging the existing customer base. <\/p>\n","post_title":"CHOW #296: Backlog Blinkers","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-296-backlog-blinkers","to_ping":"","pinged":"","post_modified":"2024-01-24 11:01:36","post_modified_gmt":"2024-01-24 11:01:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20012","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20008,"post_author":"7","post_date":"2022-05-29 17:41:22","post_date_gmt":"2022-05-29 12:11:22","post_content":"\n
In my\nopinion, one of the most overused words in the software industry is \u2018innovation\u2019.\nI understand there is a wide spectrum of enhancements that can be called \u2018innovations\u2019\n\u2013 minor enhancement that improves a business process to a module that supports\na new business process to a new application that is disruptive. Here is what I\nhave observed in software product companies that create business solutions for a\nlarge customer base \u2013 anything other than their customer support issues is called\nan innovation. These \u2018innovations\u2019 require new funding approvals within the product\norganization \u2013 usually supported by robust prioritization processes aligned to strategic\nthemes. All these innovations are expected to represent \u2018value\u2019 for the customer\nand are expected to drive software subscription and license-based revenue.<\/p>\n\n\n\n
I started wondering \u2018How would a customer of such a business software perceive value or innovation?\u2019. In general, value is defined as some feature that solves a business problem for a user. That is a meaningful definition from a user perspective. What if I wear a CIO hat? I recalled my days as the head of an IT function a few years back. Although times have changed quite a bit since then, I believe, fundamentals of IT spend decisions have not changed. Here is a perspective on how Business-IT steering committee would look at the spend:<\/p>\n\n\n\n
$\"\"$ <\/p>\n\n\n\n
Most businesses\nwould like to minimize the cost of keeping the business running and spend more\non moving the business forward. Software product license renewals are typically\npart of \u2018keeping the business running\u2019. New solutions that would help businesses\ncompete and win in the future would fall into the category of \u2018Move business\nforward\u2019. I would call these real \u2018Innovations\u2019.<\/p>\n\n\n\n
This perspective\ngives a business software product vendor a new way of looking at their innovations:<\/p>\n\n\n\n
\n
Changes that would reduce the cost\nof running the business \u2013 i.e., cost of ownership<\/li>\n\n\n\n
Changes that would help customers to\nmove their business forward (Innovative trends)<\/li>\n<\/ol>\n\n\n\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

\n
Bill is a\nProduct Manager in a large software product firm, which has decades of\nleadership in their target segment. He has over 20 years of experience at this\ncompany and has excellent relationship with the major customers of the product.<\/p>\n\n\n\n
John, the\nnew CEO, had come from a new-age software company. He proposed several new\ninnovations based on the industry trend analysis by the management consulting\nfirm hired by the board. When he spoke to Bill, he realized that there is a 3-year\nbacklog of work already planned and published to the customer base in the form\nof product roadmap. Bill was really concerned about disappointing the customer\nbase if the current roadmap is not realized. John had the support of the board\nand he directed Bill to find way to prioritize the new innovations.<\/p>\n\n\n\n
What would be your advice to Bill?<\/p>\n\n\n\n
Suggested solution:<\/strong><\/p>\n\n\n\n
Bill has a difficult task on his hands \u2013 the backlog is his baby. He needs to take a hard and objective look at the existing backlog and find ways to cherry pick items in the existing backlog that align with the new strategy of the board to focus on market trends. Rest of the items should be dropped from the backlog. He would then be able to have a meaningful conversation with John to blend the consultant\u2019s industry analysis and his own understanding of the customer base. A new prioritized backlog would then emerge that is aligned to strategic intent without sabotaging the existing customer base. <\/p>\n","post_title":"CHOW #296: Backlog Blinkers","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-296-backlog-blinkers","to_ping":"","pinged":"","post_modified":"2024-01-24 11:01:36","post_modified_gmt":"2024-01-24 11:01:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20012","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":20008,"post_author":"7","post_date":"2022-05-29 17:41:22","post_date_gmt":"2022-05-29 12:11:22","post_content":"\n
In my\nopinion, one of the most overused words in the software industry is \u2018innovation\u2019.\nI understand there is a wide spectrum of enhancements that can be called \u2018innovations\u2019\n\u2013 minor enhancement that improves a business process to a module that supports\na new business process to a new application that is disruptive. Here is what I\nhave observed in software product companies that create business solutions for a\nlarge customer base \u2013 anything other than their customer support issues is called\nan innovation. These \u2018innovations\u2019 require new funding approvals within the product\norganization \u2013 usually supported by robust prioritization processes aligned to strategic\nthemes. All these innovations are expected to represent \u2018value\u2019 for the customer\nand are expected to drive software subscription and license-based revenue.<\/p>\n\n\n\n
I started wondering \u2018How would a customer of such a business software perceive value or innovation?\u2019. In general, value is defined as some feature that solves a business problem for a user. That is a meaningful definition from a user perspective. What if I wear a CIO hat? I recalled my days as the head of an IT function a few years back. Although times have changed quite a bit since then, I believe, fundamentals of IT spend decisions have not changed. Here is a perspective on how Business-IT steering committee would look at the spend:<\/p>\n\n\n\n
$\"\"$ <\/p>\n\n\n\n
Most businesses\nwould like to minimize the cost of keeping the business running and spend more\non moving the business forward. Software product license renewals are typically\npart of \u2018keeping the business running\u2019. New solutions that would help businesses\ncompete and win in the future would fall into the category of \u2018Move business\nforward\u2019. I would call these real \u2018Innovations\u2019.<\/p>\n\n\n\n
This perspective\ngives a business software product vendor a new way of looking at their innovations:<\/p>\n\n\n\n
\n
Changes that would reduce the cost\nof running the business \u2013 i.e., cost of ownership<\/li>\n\n\n\n
Changes that would help customers to\nmove their business forward (Innovative trends)<\/li>\n<\/ol>\n\n\n\n
Value<\/strong> =<\/strong> Reduction in cost of ownership \u00a0\u00a0\u00a0\u00a0+<\/strong> \u00a0\u00a0\u00a0\u00a0Business potential of innovative trends<\/p>\n\n\n\n
Product\nManagement function in software product organizations is often tasked with formulating\nthe product strategy and managing the backlog. To reduce cost of ownership, Product\nManagers need a deep understanding customer\u2019s IT operational cost structure as\nwell as business usage patterns. To identify innovation opportunities, they\nneed a deep understanding of business trends in customer\u2019s domain as well as\ntechnology trends that could be disruptive. Today\u2019s backlog itself should be split\ninto broadly two categories: ToC Backlog and Trend Log (trends in customer\u2019s\nbusiness). At a strategic level, leadership can decide their mix depending on\nthe product lifecycle and their overall product portfolio.<\/p>\n\n\n\n
In conclusion,<\/strong> value and innovation are viewed purely from customer perspective with a clear intent to support customer\u2019s business strategy while leveraging technology trends.<\/p>\n\n\n\n
anand<\/a><\/p>\n","post_title":"Trend log, no backlog","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"trend-log-no-backlog","to_ping":"","pinged":"","post_modified":"2024-01-24 11:02:31","post_modified_gmt":"2024-01-24 11:02:31","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20008","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19916,"post_author":"10","post_date":"2022-04-22 16:49:26","post_date_gmt":"2022-04-22 11:19:26","post_content":"\n
Introduction<\/h2>\n\n\n\n
In my previous two articles Why do we need a \u2018Three Track\u2019 Lean-Agile Product Development?<\/a>, and \u2018Three Track\u2019 Lean-Agile Development: Part 2 \u2013 Opportunity Space<\/a> , I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Three Tracks of Activities<\/h3>\n\n\n\n
I then proposed that an improved\nproduct creation process needs three tracks of Practices to effectively transform\nideas to value. These practices are guided with a set of questions and\nincorporate corresponding activities. <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
The first track is Lean Discovery\nand is all about discovering the \u2018what\u2019 aspect of the product. It also is about\n\u2018who\u2019 to build it for, emphasizing customer and user centricity. The product\ncontour gets defined in this track. This is also referred to as Product\nDefinition. The second is Lean Agile development where the product actually\ngets built and comes to life. The user experience, product architecture and\ntechnical aspects of the product get defined. The third is Lean Deployment\nwhere the product gets to the end users and its usage gets monitored and\nmeasured to first validate the original assumptions of the need and to make\nimprovements in the future.<\/p>\n\n\n\n
Activity Spaces mapped to Tracks<\/h3>\n\n\n\n
Then I linked the tracks to\nActivity Spaces where certain activities get done with respect to the product. These\nare guided by a set of key questions and driven by practices related to the\nProduct.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Opportunity Space in brief<\/h3>\n\n\n\n
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. <\/p>\n\n\n\n
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner. <\/p>\n\n\n\n
In this article, I will describe in detail the Solution Activity Space.<\/p>\n\n\n\n
Solution Space<\/h2>\n\n\n\n
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions<\/p>\n\n\n\n
Is the Solution worth building?<\/h3>\n\n\n\n
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?<\/p>\n\n\n\n
How can we build the Right Solution?<\/h3>\n\n\n\n
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.<\/p>\n\n\n\n
\n\nLet me outline some key characteristics of such an approach to building solutions. \n\n<\/p>\n\n\n\n
Agile Teams<\/h3>\n\n\n\n
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other\u2019s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.<\/p>\n\n\n\n
Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n
Release Early & Often<\/h3>\n\n\n\n
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called \u2018develop in cadence and release on demand\u2019. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.<\/p>\n\n\n\n
Evolving Architecture and Design <\/h3>\n\n\n\n
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development. <\/p>\n\n\n\n
Feature Roadmap<\/h3>\n\n\n\n
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.<\/p>\n\n\n\n
Feature Prioritization<\/h3>\n\n\n\n
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay \/ Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.<\/p>\n\n\n\n
Discovery & Develop Tracks - Touch points<\/h3>\n\n\n\n
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
In this part of the article, I\ndefined Solution space where the Product teams develop and deliver features as\npart of a product which is of customer value. There is huge merit in teams\nfollowing a Lean Agile methodology in this solution space. I outlined some\nessential hallmarks of an Agile team and the way they approach activities\nwithin the Solution space. <\/p>\n\n\n\n
They are first of all\ncross-functional in membership so that they can develop end to end customer\nvalue. This customer value is delivered as early and often so that the team\nknows they are in the right direction and has a chance to apply course\ncorrections before too much investments and efforts. A fixed team size is\nusually maintained which creates a solid team environment and as a team they\ncan deliver. <\/p>\n\n\n\n
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other. <\/p>\n\n\n\n
Another thing that teams have to\nmanage well in the solution space is the ability to evolve their product design\nand architecture to accommodate features as they grow. There is no big-bang\napproach to design at the launch of new development. The teams have to build-in\nrobustness in such a design to absorb new features on a continuous basis. <\/p>\n\n\n\n
In the next article in the series, I deep-dive into the Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.<\/p>\n\n\n\n
<\/p>\n","post_title":"Three Track Lean-Agile Development: Part 3 - Solution Space","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"three-track-lean-agile-development-part-3-solution-space","to_ping":"","pinged":"https:\/\/pm-powerconsulting.com\/blog\/why-do-we-need-a-three-track-lean-agile-product-development-1\/\nhttps:\/\/pm-powerconsulting.com\/blog\/three-track-lean-agile-development-part-2-opportunity-space\/","post_modified":"2024-01-23 12:58:59","post_modified_gmt":"2024-01-23 12:58:59","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19916","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19825,"post_author":"18","post_date":"2022-04-03 19:29:21","post_date_gmt":"2022-04-03 13:59:21","post_content":"\n
Great software is created by the great teams. Therefore, building a team where team work happens naturally is a key to success with software development. Agile approaches to software development emphasize team work and advocate practices that promote collective ownership of goals, collective problem solving and decision making. However, despite such practices, additional measures are needed for the spirit of team-work to emerge in the team. <\/p>\n\n\n\n
We know from Tuckman\u2019s model that teams go through four\nstages \u2013 Forming, Storming, Norming and Performing. Skilled coaches help the\nteams to move from Forming stage to Performing stage quickly. One of the resources\nthey use in this endeavor is the \u201cTeam Working Agreement\u201d. <\/p>\n\n\n\n
Team Working Agreement is created in the Forming stage of\nthe team. In this stage, team members are new and engage in an attempt to\nunderstand each other. As the interactions increase, they build a mental model of\nhow to interact with different individuals in the team and behave accordingly. However,\nthis model may be different for different individuals. Team working agreement\nfacilitates establishing a common ground for working in the team. <\/p>\n\n\n\n
In the Forming stage, sometimes well-intentioned actions of\na team member, may get misinterpreted and this may have negative impact on the personal\nrelationship among some team members. Prevention of such misunderstanding and promotion\nof actions and behaviors for improving the team spirit is the purpose of Team\nWorking Agreement. A junior person in the team may not be able to express his\/her\nviews if he\/she sees that his\/her views differ from those of the seniors. A Team\nWorking Agreement which states, \u201cIt is OK to disagree with your team members.\nExpress yourself freely\u201d, explicitly encourages every individual to voice his\/her\ndisagreement. The team agreement may also provide some guidance on how to voice\ndifference of opinion by stating something like, \u201cNo personal attacks, we only attack\nissues\u201d. Team members who are shy of expressing themselves or carry the fear of\nbecoming a laughing stock if they speak, would be able to get over their fear\nif there is a team agreement that states, \u201cWe question the merit of the ideas\nand not of the people\u201d. All of us have some\nideas about what good team behavior means. However, these ideas differ from\nperson to person. Team Working Agreement helps us establish a common\nunderstanding of the right behavior in the team. <\/p>\n\n\n\n
While on the one hand, Team Working Agreement helps us\nunderstand the right behavior, on the other hand it may also tell what is not\nto be done. \u201cDo not interrupt people when they are making a point. Let them\ncomplete what they are saying\u201d, is a good example of what is not to be done.\nSimilarly, a statement like \u201cStop starting, start finishing\u201d conveys to the\nteam that they should not leave a story unfinished and start working on the new\nstory.<\/p>\n\n\n\n
Team Working Agreements could also be useful in establishing\nright pattern for functioning of the team. In one of the teams I coached, some\nteam members preferred coming early and going early while others preferred to\ncome late and go late. This team assigned support activities for Indian clients\nto the members coming early whereas European customers were assigned to the\nmembers who preferred to work late hours. At the same time, team had an\nagreement that all team members will be in office from 12:00 pm to 6:00pm which\nensured that events like daily meeting could happen on cadence and sufficient\ntime was available for interactions between team members. Team Working agreement\nhelped them address individual\u2019s needs as well as needs of their clients and also\naddress the activities required by their process. <\/p>\n\n\n\n
For a Team Working Agreement to be effective, it should be\ncreated by the team. All the team members should contribute to it. A coach or Scrum Master may facilitate its\ncreation but its content should come from the team. Then only it will be owned\nby the team and will serve its purpose effectively. <\/p>\n\n\n\n
All team members should explicitly express their commitment to the Team Working Agreement. They should remember the Team Working Agreement whenever they perform process checks. It is a good idea to do this during the Retrospectives. Since all team members own the agreement, if it is broken by anyone, any member of the team can question it. Every instance of breaking Team Working Agreement should be reviewed by the team and sometimes such review may lead to the need for a change in the Team Working Agreement which the team may discuss and adopt. <\/p>\n\n\n\n
The Team Working Agreements should be limited in number so that\nteam members could remember them easily. It is advisable to keep the number of\nagreements in single digit. In most cases, five to seven agreements would be\nsufficient. They should be articulated in simple language. Short statements are\neasier to remember and hence are more effective. <\/p>\n\n\n\n
The Team Working Agreements are useful for building trust,\npromoting open communication and defining the working discipline among the team\nmembers. These are the elements that contribute to making the team self-organized\nwhich is the essence of agility. <\/p>\n\n\n\n
Although it is good to create the working agreement during\nForming stage, if a team is working without it for some time, it is never too\nlate to create one! That will only help in improving the team work. <\/p>\n\n\n\n
To summarize, the Team Working Agreement is a simple yet powerful tool that promotes right team behavior by making implicit understanding, explicit!<\/p>\n","post_title":"Team Working Agreement \u2013 Necessity or Nice to Have?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"team-working-agreement-necessity-or-nice-to-have","to_ping":"","pinged":"","post_modified":"2024-01-25 13:22:10","post_modified_gmt":"2024-01-25 13:22:10","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19825","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19649,"post_author":"30","post_date":"2022-02-19 12:24:26","post_date_gmt":"2022-02-19 06:54:26","post_content":"\n
Recently, when I was making the morning Congee, it was a lightbulb moment \u2013 to see different approaches similar to some patterns and anti-patterns we see in teams and organizations with transformation initiatives.<\/p>\n\n\n\n
We see the organization as a structured and organized system, that has settled into its own pace and shape, even if not uniform.<\/p>\n\n\n\n
Any change is likely to bring in uncertainty, anxiety among the members and hence we want to tread cautiously. But, we have a rough idea of what element to bring in \u2013 be it digital transformation or delivery agility or process efficiency, defect prevention etc.<\/p>\n\n\n\n
One consideration that usually weighs heavy is not to ruffle any feathers the wrong way. This is the case of the mot common anti-pattern, of 'action on the periphery'<\/p>\n\n\n\n
While this may appear as a lot of activity involving the teams \u2013 and, in many cases, just the team members \u2013 the core portions may still remain untouched or influenced very little.<\/p>\n\n\n\n
The result is \u2013 patchy impact, that would not give any significant or sustainable improvement.<\/p>\n\n\n\n
When you get external support from a consultant or coach, to get an outside-in perspective, the effects are still patchy.<\/p>\n\n\n\n
From our experience, I can say that to get a greater impact, the scope of transformation initiatives should involve \u2013 and preferably led, with active participation by, senior leaders.<\/p>\n\n\n\n
The actual catalyst for such approaches would be a coach who has access to and is connected in the day to day activities of the teams, through embedded coaching.<\/p>\n\n\n\n
In this approach the coach is pretty much part of the team in various activities as an observer and guide. This helps the coach get a better understanding of the context and constraints and relate to the needs and aspirations of the team. This also helps build a trusted relationship between the coach and the teams.<\/p>\n\n\n\n
Establishing communities of interest and practice \u2013 with the guidance of the coach as needed \u2013 will help in establishing connections across the organization and also enable constructive collisions of ideas across teams. Such opportunities can accelerate breakthrough practice improvements across the board.<\/p>\n\n\n\n
This also helps in creating more homogeneous ways of working across the organization.<\/p>\n\n\n\n
Now, it is the time to assess the achievements and refine approaches needed to sustain the benefits of transformation across the organization. Be ready to add the required additional elements [water in the case of the Congee]<\/p>\n\n\n\n
While you may get started with this autopilot mode where teams are taking ownership and also self organizing among themselves, having platforms for sharing and learning as well as periodic peer reviews and shared improvement initiatives will help sustain the excellence culture.<\/p>\n\n\n\n
I have captured the above thoughts in a visualization of making Congee, in about 6 minutes.<\/p>\n\n\n\n
\nhttps:\/\/www.youtube.com\/embed\/8A1LPIHr7sU\n<\/div><\/figure>\n\n\n\n
Now that you have the recipe for success for your organizational transformation, what is holding you back?<\/span><\/p>\n\n\n\n
Do share your stories and analogies that have worked well or not so well in your context.<\/p>\n","post_title":"Transform your organization like you would make Congee","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"transform-your-organization-like-you-would-make-congee","to_ping":"","pinged":"","post_modified":"2024-01-29 11:34:04","post_modified_gmt":"2024-01-29 11:34:04","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19649","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19318,"post_author":"28","post_date":"2021-11-01 12:50:50","post_date_gmt":"2021-11-01 07:20:50","post_content":"\n
$\"Point$
Change the way you look at things and the things you look at change - Wayne Dyer<\/figcaption><\/figure>\n\n\n\n
A few years ago, when I was in a boutique-sized software service providing organization, we received a call from the IT team of an international bank. They had one important delivery to make in six months. But, their project plan, using the existing development model, projected the earliest delivery in 14 months. Some of the executives thought the Agile Development Model would rescue them. After internal deliberations, they had decided to work with us, hence no competition. Considering their team size and product complexity, such engagements would run for a couple of years easily. <\/p>\n\n\n\n
For us not having such long-running contracts in sales book in those days, this was an attractive deal. Did we sign it?<\/p>\n\n\n\n
The actual\nstory starts here. <\/p>\n\n\n\n
One of the\nvery good things about our organization was the value system we believed in. <\/p>\n\n\n\n
After a quarry of discussions regarding the needs of our customers and potential approaches regarding the matter in question, we came to a few key conclusions. <\/p>\n\n\n\n
Despite the invigorating opportunity, we would not sign the contract and begin immediately.<\/li>
We would do a discovery workshop first. The objective was to arrive at a clear problem statement.<\/li>
We would form a small task force with 3 people, a hands-on Technical Architect, a Senior Analyst, and a Solution Architect. <\/li>
We would request the customer to prepare a list of participants for the workshop. The list preferably shall include key stakeholders\/decision-makers in their software development process.<\/li>
The workshop would run for 3 days. We will present our findings on the final day post-lunch. <\/li><\/ul>\n\n\n\n
We communicated this to our customer\u2019s surprise as they were expecting a draft contract from us. Still, they reluctantly agreed to this proposal. Fees for the 3 days workshop were agreed and the necessary paperwork was done.<\/p>\n\n\n\n
We chalked out a plan for the 2.5 days. A timetable was prepared with sessions, objectives, expected outcomes, participants, preparations to be done, etc, and shared with the customer. <\/p>\n\n\n\n
The\nsessions were primarily design thinking tools. To name a few, we had planned\nfuturespectives, retrospectives, value stream mapping, pain point analysis,\nanchors and engines, and so on. <\/p>\n\n\n\n
Myself, with a couple of my colleagues, conducted the workshop. the workshop was conducted as a mini agile project with daily sprints. The customer team had 25+ senior executives actively involved in and participated for all three days. Except for a few minor changes, we managed to complete the plan. The large board room, we were using, was filled with stickies, diagrams, voting marks, scribbled notes, hand-drawn charts, and a lot of constructive discussions. <\/p>\n\n\n\n
By the time we were ready with the final presentation, the writings were clearly on the wall, literally. The customer team themself concluded that adopting the agile process may not be a tactical solution to the challenges they faced. They unanimously agreed that agile adoption would help them strategically in the long run, but will not solve their immediate problems. So they decided not to do agile then.<\/p>\n\n\n\n
Takeaways:<\/p>\n\n\n\n
Agile is not a silver bullet<\/li>
Saying \u2018NO\u2019 to work (not signing the long-term contract in the first place) on pragmatic grounds is not bad. It builds trust. (As a side note, even though we did not work with that customer then, we had a fantastic relationship and got much more meaningful work later)<\/li>
Collaborative workshops help. They are transparent, objective, and emergent. <\/li>
Definition of the problem and objectives reduce communication overhead. <\/li>
Design Thinking tools enable visual communication and bring people on the same page.<\/li>
Agility is a mindset. Embracing a tool or process may not be sufficient until mindset and culture change.<\/li><\/ul>\n","post_title":"To or Not-To Agile - An Experience Report","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"to-or-not-to-agile-an-experience-report","to_ping":"","pinged":"","post_modified":"2024-03-24 07:46:29","post_modified_gmt":"2024-03-24 07:46:29","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19318","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19083,"post_author":"20","post_date":"2021-08-30 13:47:24","post_date_gmt":"2021-08-30 08:17:24","post_content":"\n
This crossword uses the theme Lean Thinking; i.e. all answers are term that are relevant to Lean Thinking. All the best.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","post_title":"Agility Crossword","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"agility-crossword","to_ping":"","pinged":"","post_modified":"2024-01-30 05:49:55","post_modified_gmt":"2024-01-30 05:49:55","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"3","filter":"raw"},{"ID":18849,"post_author":"27","post_date":"2021-07-04 22:35:37","post_date_gmt":"2021-07-04 17:05:37","post_content":"\n
It was an evening, I started walking towards the bazaar\nnearby to purchase few items for home. \nFrom the first turning from my house, I noticed that the bicycle\nrepairing shop was open, and quickly remembered to ask the mechanic the status\nof my son\u2019s bicycle that I gave for some repair a couple of weeks ago. I had to cross this bicycle repair shop, on\nmy way to the bazaar. I noticed, that\nthe mechanic, who was busy working on something saw me walking towards his\nshop. As I approached his shop, I could\nsee that his helper boy in the shop brought my son\u2019s bicycle and placed it in a\nqueue like order, that appeared to me as if he is going to work on my son\u2019s\nbicycle, next. When I reached the shop,\nwe both smiled. <\/p>\n\n\n\n
I said, \u201cHello Kumar!\u201d \u2013 Kumar is my cycle mechanic.<\/p>\n\n\n\n
\u201cGood evening sir! Here is your son\u2019s bicycle, and I will\nwork on it next as soon as I finish this!!\u201d \u2013 he was pointing to what he is\ncurrently working on.<\/p>\n\n\n\n
I acknowledged, and started walking towards the bazaar. I was happy that the bicycle would be done\nand delivered in a couple of days from today. \nHowever, my inner voice did not agree with my belief. It reflected those learnings from the past.<\/p>\n\n\n\n
When I was young, I grew up in the western Ghats \u2013 those areas where hydel power projects were built. My father was working in those hydel projects then. In those areas, where I did most of my schooling, school drop outs were not uncommon. One such as dropped out classmate and a friend of me, went on to learn tailoring in his brother\u2019s tailoring shop. Learning tailoring is an involved apprenticeship. One has to have lots of patience to do all sorts of chore in the tailoring shop for months, before being allowed to touch and paddle the tailoring machine. In few years\u2019 time he picked up the art of tailoring amazingly well, and went on to set up a shop on his own. This shop was small, just measuring 10\u2019x10\u2019, at the entrance of the market in the adjacent town, which was on top of a hill from the hydel power station.   He had just one tailoring machine, one interlocking machine \u2013 which was considered a speciality in those days. He fixed a broad table for cutting, above which shelves built like pigeonholes to store cloths. He successfully found another dropout, apprentice boy, same as he was to help him.   If someone is walking up the hill from the power project\u2019s residence area, one can see them walking the complete stretch sitting in his shop. This boy was positioned to sit on a stool to have a good view of those walking uphill to the market. Anyone who lived in such hill stations, knows that they naturally develop this ability to identify persons, walking far away at a distance, on another hill, just by looking at their profile, and walking rhythm. I used to visit the shop and chat with him during weekends and holidays. One morning when I was in the shop talking to my friend,<\/p>\n\n\n\n
\u201cKesavan sir is coming to the market!!\u201d \u2013 the boy exclaimed.\n<\/p>\n\n\n\n
\u201cWhere is he now?\u201d \u2013 my tailor friend, Ravi asked.<\/p>\n\n\n\n
\u201cNear the plumbing stores\u201d.<\/p>\n\n\n\n
My friend who was stitching stopped his work exactly ten minutes later. He got up and went to the cutting table to pull out a shirt cloth from the shelf, neatly spread it on the table, took the bulk measurement book searching through the pages. He took the blue marking chalk and measurement tape that was hanging around his neck, and started marking. <\/p>\n\n\n\n
\u201cRavi, why did you stop this stitching work in the middle\nand went for cutting?\u201d \u2013 I asked.<\/p>\n\n\n\n
\u201c\u2026.\u201d \u2013 he did not respond.<\/p>\n\n\n\n
I saw Kesavan \u2013 a staff from the hydel project, approaching\nthe entrance of the market. <\/p>\n\n\n\n
\u201cGood morning \u2013 Kesavan sir!\u201d \u2013 Ravi welcomed him with a\nsmile.<\/p>\n\n\n\n
\u201cGood morning Ravi. \nHow are you? Have you started\nworking on my clothes?\u201d \u2013 he casually enquired.<\/p>\n\n\n\n
\u201cYes, yes. I just started. I just started marking the measurements, and you walked in. It was perfect timing!! \u201c\u2013 my tailor friend pretended as if it is an auspicious coincidence.<\/p>\n\n\n\n
I could visibly see a happy Kesavan, looking at his shirt cloth neatly spread on the cutting table with markings, struggling to hide his happiness.<\/p>\n\n\n\n
As soon as Kesavan stepped out of the shop, my friend rushed\nback to the tailoring machine to resume from where he left. Kesavan\u2019s shirt cloth, partially marked for\ncutting was on a corner of the cutting table, until the time Kesavan left the\nmarket to go home. Then the cloth was\nrolled up, tied and found its place in the pigeon hole.   This conversation continued for many \u2013 like:<\/p>\n\n\n\n
\u201cSee the boy is stitching the buttons for your shirt. Once it is ready, I have to just iron and\ndeliver it to you.<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your shirt is almost ready. I have to just do the collar portion. I am waiting for a good quality collar canvas\nfrom my supplier and he promised me to deliver tomorrow<\/em>\u201d.<\/p>\n\n\n\n
\u201cSee your interlocking work is in progress!!<\/em>\u201d<\/p>\n\n\n\n
Observing this for some time, I understood that my friend\nhas learned the technique of keeping his customers happy by way of showing them\nthe work in progress (WIP) than the actual work delivered. I also realized that his shop was\nstrategically located at the entrance of the market to promptly manage the WIP\nshow. <\/p>\n\n\n\n
When I spoke to some of his customers, like Kesavan,\nseparately, they seem to be quite happy with this style of working rather\nwaiting for the delivery date that is agreed with Ravi. <\/p>\n\n\n\n
\u201cEven a week\u2019s delay is fine with Ravi!! But we can be sure that he is working on my\norders!!\u201d.<\/p>\n\n\n\n
At some point in time, many years later, after learning TPS\nand Lean, I felt that this tailor shop of my friend manages everything in WIP. There is nothing in raw material or as\nfinished. As a result of this WIP, I\nobserved that there was too much of switching between orders, and he started\ncommitting mistakes, and some of those lead to lots of rework. But this WIP style of working hasn\u2019t changed.<\/p>\n\n\n\n
Reflecting on this tailoring shop and relating it to many\npractices I saw in various other industries later in my professional career gave\nraise to this question \u2013 \u201cwhy teams or organizations are struggling to limit\nWIP \u2013 knowing well that limiting WIP is beneficial?\u201d.<\/p>\n\n\n\n
\u201cAre we using WIP as a progress indicator \u2013 that prohibits\nus from limiting WIP?\u201d<\/p>\n\n\n\n
\u201cAre we using WIP as a tool to keep the customers happy \u2013 like my friend running the tailoring shop?\u201d\u00a0 - many engineering industry subcontractors exhibit this behaviour.\u00a0 Subcontractors to large manufacturers deliberately plan and run that customer's product in the shop especially during those manufacturer\u2019s periodical visit or inspection thus increasing their WIP.<\/p>\n\n\n\n
One common scenario in Software Development is that when\npresented with a requirement, the team always asks this question \u2013 <\/p>\n\n\n\n
\u201cWhen this is to be done?\u201d. \n<\/p>\n\n\n\n
\u00a0\u201cYesterday\u201d.\u00a0 \u00a0\u2013 this is the response from many managers with a sarcastic smile on their face. Managers seems to take pride in such responses thinking that this is an authoritative style of communicating urgency.\u00a0 I know some teams, secretly, within themselves, refer to such managers as \u201cYesterday manager\u201d.\u00a0 This behaviour leads to, what is like Kesavan walking uphill to the market, and the Tailor halts all the work to start planning Kesavan\u2019s shirt \u2013 team stops working on everything they are into and start the new work, increasing WIP.<\/p>\n\n\n\n
When WIP grows unmanageable \u2013 we see a switch in communicating the progress in terms of percentage (%) of progress (like 80% complete) or phrases like \u201calmost done\u201d or \u201cnearly done\u201d or \u201cclose to completion\u201d and so on \u2013 like the collar canvas response of my tailor friend.<\/p>\n\n\n\n
After purchasing the items from the bazaar, I started walking back home. While nearing the cycle mechanic\u2019s shop, I saw the seat unplugged, mud-guard removed from my son\u2019s bicycle \u2013 indicating that the work has begun. Kumar smiled at me, and said \u201cwill be ready within a week\u2019s time, sir!!\u201d. <\/p>\n\n\n\n
Forgetting all that I learnt, especially those I thought I have mastered like TPS, Lean etc., all falling apart, I behaved like Kesavan, struggling to hide my satisfaction.\u00a0 Kumar knew that he made his customer happy by way of adding one more item to his WIP.<\/p>\n\n\n\n
After reaching home, placing those items I bought from the bazaar in the shelf.\u00a0 I sat down, and the book \"The Machine that Changed the World<\/em>\" \u2013 was on my table, appeared smiling at me!!<\/p>\n\n\n\n
V Sairam<\/a><\/p>\n\n\n\n
Consultant - Agile Coach<\/p>\n","post_title":"My WIP Days","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"my-wip-days","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:25","post_modified_gmt":"2024-01-25 13:54:25","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18849","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":18533,"post_author":"27","post_date":"2021-03-26 10:01:30","post_date_gmt":"2021-03-26 04:31:30","post_content":"\n
Scaling Agile discussions always\nrevolve around dependencies. At some\npoint, it even appears as if once the problem of dependencies is addressed,\nthere is nothing more to do in Scaling Agile. \nTo address the dependency, challenge some approaches recommend additional\nceremonies \u2013 like Scrum of Scrums, some new co-ordination roles, etc.<\/p>\n\n\n\n
Is dependency a real\nchallenge? <\/p>\n\n\n\n
Anyone who has some understanding\nabout Agile will know Toyota Production System (TPS) and Lean \u2013 which is one of\nthe inspirations for Agile. Let\u2019s take a\nclose look at one of the popular auto products of Toyota Corporation \u2013 the\npassenger car and delve little into this. \n<\/p>\n\n\n\n
How many parts (BoM \u2013 Bill of\nMaterials) together make up a Toyota car? \nIt is roughly 30,000 \u2013 counting every part down to the smallest screw. That is, 30,000 parts\/components come\ntogether to deliver a value to the customer. \n<\/p>\n\n\n\n
Now, more than 80% of these\nparts, that is roughly 25,000, are not manufactured by Toyota in their\nfactories but are bought out from various other part\u2019s manufactures \u2013 that is \u2013\nsuppliers or vendors. Interestingly,\nfrom the remaining 20%, again all of those parts are not manufactured in the same\nToyota factory \u2013 from where the finished car is dispatched. They are distributed across a number of\nToyota\u2019s manufacturing facilities. For\nexample, the passenger car engine is manufactured in one of the Toyota\u2019s factories\nspecializing in Engine Manufacturing. Again,\nto understand it better, a smallest Engine has around 300-parts \u2013 which will\nhave their suppliers. Suppliers or\nvendors are multi-level. Remember, these are parts and not raw materials.<\/p>\n\n\n\n
Just look at this massive multi-level\ndependency<\/strong> of this auto industry, from where the \u201cLean Principles<\/strong>\u201d\nhave emerged.<\/p>\n\n\n\n
This huge dependency is definitely a Challenge.\u00a0 Not just a Scaling Challenge, but also a \u201cFlexibility Challenge\u201d<\/strong>.\u00a0 With such a huge dependency, how can they \u201cRespond to Change\u201d<\/strong> \u2013 that too for Toyota \u2013 when it proudly says that they make cars exactly the way their customers\u2019 orders them? <\/p>\n\n\n\n
And to quote the most popular statement of Taiichi Ohno on Toyota Production System, <\/p>\n\n\n\n
\u201cAll we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash.\u00a0 And we are reducing that time line by removing the non-value-added wastes<\/em>\u201d.<\/p>\n\n\n\n
TPS has to be deeply understood,\notherwise one won\u2019t know how \u2018non-value-added wastes\u2019<\/em> are removed in a\nsystem involving thousands of suppliers \u2013 that is thousands of external\norganizations. <\/p>\n\n\n\n
When Japanese car manufacturers\ndecided to set up their facilities in North America, they had two major\nchallenges confronting them. First, they\nhave to compete with well-established auto giant brands in North America, the\nFord and General Motors. Second, in\norder to compete, they have to depend only on those suppliers of auto parts who\nare already supplying to their competitors as it is obviously impossible to ask\nall their suppliers in Japan to set up their factories in North America. The second, the supplier, is the biggest\nchallenge for any car manufactures while setting up their manufacturing in\nanother geography. Remaining competitive,\nwhile still depending on the same pool of suppliers who supply to the\ncompetitors for more than 80% of the components \u2013 is the key success factor for\nToyota while they expanded in North America? \nHow did Toyota address this?<\/p>\n\n\n\n
While building their factories in\nNorth America, Toyota identified their suppliers for the auto-parts. These\nsuppliers are the ones who are already supplying to their competitors, Ford and\nGeneral Motors. Managers and Engineers from Toyota started working with those\npart\u2019s suppliers \u2013 in the supplier\u2019s factories \u2013 by teaching them concurrent\nengineering, adaptive planning, calculating batch sizes, flow, pull based\nsystems, visual management, stop-and-fix etc. Simply the TPS and Lean. The part\u2019s manufacturers learnt and applied them\nwith the help of those Managers and Engineers from Toyota. Some of them even changed their shop-floor\nlayouts to reduce transportation wastes. \nThis helped those auto-parts manufacturers to optimize their production,\nthus supply to Toyota at a competitive price, still protecting their margin and\nat the same time, improve their margins in the supplies to Toyota\u2019s\ncompetitors.<\/p>\n\n\n\n
Toyota invested in this early\nengagement with vendors and helped them to be Lean. This is the key success\nfactor in Toyota becoming competitive in North America and was able to take on\nthe two well established brands in the market. \nThis appears very simple to read \u2013 but not easy. <\/p>\n\n\n\n
But what are those \u201cLean\/TPS\nprinciples\u201d behind? I would like to\nlimit this discussion to three of those principles, though there are many more\nthat could be attributed and elaborated.<\/p>\n\n\n\n
\u201chelping partners to be Lean<\/strong> \u2013 or respect\nyour extended network of partners, challenge them and help them to improve!!\u201d. Toyota invested in helping their partners to\nbe Lean. This way, the supplier\u2019s\nmanufacturing facility is in \u201cno way\u201d \u2013 different from their own. This is what helps in creating a \u201cseamless\u201d production,\nwhere the work flows without any pause or wait. \nThis is key to \u201coptimizing the whole\u201d.<\/li>
\u201cgo to gemba<\/em> \u2013 go to the place where\nvalue is being added<\/strong> and see for yourself to thoroughly understand the\nsituation (genchi genbutsu<\/em>)\u201d. The\nmanagers and engineers who were present in the suppliers manufacturing facility\n(the place where value is being added), personally studied and understood their\nways of working, taught them experimentation, and helped them implement the\nchanges for improvement. They did not\n\u201chand-off\u201d instructions, plans or just recommend \u2013 but owned it along with\ntheir supplier\u2019s team.<\/li>
\u201cmanager-teacher with in<\/strong>. Grow leaders internally who understands the\nwork and live the philosophy \u2013 and they are the ones who teaches\u201d. The managers and engineers who went to help\ntheir suppliers are the ones who understand the work in great detail and lives\nthe Toyota Philosophy. \u2018managers and\nteachers within\u2019 - is where the person who manages is the one who always\nteaches his team, and is the one who lives with the team to help them practice\nthe teachings. The key message here is\nthat \u2013 no one external to the system teaches those within the system<\/em>.<\/li><\/ul>\n\n\n\n
While I was sharing this with a\nsmall group of agile practitioners, one of them asked \u2013 have any of us seen a\nsoftware system having thousands of components\/APIs\/Services built together,\nlike this passenger car, delivering a value to the customer?<\/p>\n\n\n\n
\u201c\u2026\u2026..\u201d \u2013 No one responded.<\/p>\n\n\n\n
I understood that the moment we STOP\nseeing a dependency<\/strong> - as something that is impeding, but as a constraint<\/strong>,\nthe TPS and Lean principles turns out to be highly valuable. On the other hand, if we continue to view\ndependencies as one that is to be removed, we start finding ways to fix one \u2013\nwhich systemically creates many more within \u2013 and keep us busy, complaining.<\/p>\n\n\n\n
V Sairam - Coach and Principal Consultant<\/a><\/p>\n","post_title":"Is Dependency a real Challenge? Are we learning?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-dependency-a-real-challenge-are-we-learning","to_ping":"","pinged":"","post_modified":"2024-01-25 13:54:44","post_modified_gmt":"2024-01-25 13:54:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18486,"post_author":"33","post_date":"2021-03-20 10:33:34","post_date_gmt":"2021-03-20 05:03:34","post_content":"\n
There are\nmany discussions going on in the industry on the appropriateness of the word\nScrum Master: <\/p>\n\n\n\n
Why\nnot Agile Master? Is Scrum = Agile? <\/li>
It\u2019s\nnot gender neutral. Would women playing the role be Scrum Mistress?<\/li>
If\nit\u2019s about mastery, does just a certificate make someone a Master? <\/li>
If\nthis role is Scrum Master, are the rest of the team Scrum Slaves?<\/li>
\u2026..\nand so on. <\/li><\/ul>\n\n\n\n
Ah, what\u2019s in a name? Why bother? Name is very important. It creates the identity \u2013 how one perceives about oneself and how others look at them. Subconsciously it influences the mindset and behavior, both by the person playing the role and the others interacting with that role. <\/p>\n\n\n\n
There are\nmany negative impacts of over-emphasis of Scrum as Agile. Agile is more than\nScrum. Scrum, in essence, is a lightweight iterative project management\npractice, dealing with estimation, planning, tracking and continuous improvement.\n <\/p>\n\n\n\n
Here are\nsome patterns (actually Agile anti-patterns) negatively impacting the industry because\nof Agile = Scrum syndrome:<\/p>\n\n\n\n
Biggest\ncasualty of over-emphasis of Scrum as Agile, is the lack of focus on\nArchitecture, good Engineering practices and Product Quality. People think if\nthey are doing some sprints, stand-ups, retros, the organization is Agile. <\/li>
Leaders\/Managers\nthink Agile is all about changing the Team to implement Scrum and no change\nrequired in them and at their level. <\/li>
Diminished\nvalue of Scrum Master role. It\u2019s a Leadership role; but it gets reduced to\nproject secretary role, just scheduling and coordinating Scrum ceremonies\/events.\nMissing the outcome focus on Agility. <\/li>
Scrum\nMaster role is highly under-valued and under-staffed by Leaders\/Managers \u2013\nmultiple-hat SMs, putting junior people for the role, rotating part-time SMs, etc.\n<\/li>
SM\nrole is not an aspirational role in most organizations, as Leaders\/Managers don\u2019t\nsee it as an important role. SM role becomes a dead-end as organization does\nnot have answer to what next after SM role. <\/li>
\u2026.\nand more.<\/li><\/ul>\n\n\n\n
We can\naddress these issues if we relook at this important role and reposition SM role\nas a leadership role. <\/p>\n\n\n\n
Purpose,\nAutonomy and Mastery are the important ingredients for Agility. The Purpose\ndimension, the business\/customer problem to solve, is anchored by Product Owners\/Squad\nLeaders. The Mastery dimension is anchored by Engineering Managers\/Chapter\nLeaders. The Autonomy dimension, building a self-organizing collaborating autonomous\nteam, delivering higher value to Customers faster, is anchored by Scrum Masters.\nIsn\u2019t it more appropriate to call this role as Agile Delivery Lead?<\/strong> <\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
In Scrum Master\nname, the scope becomes Scrum and focus goes on to the Scrum ceremonies\/events.\n<\/p>\n\n\n\n
In Agile\nDelivery Lead, the focus is on<\/p>\n\n\n\n
Agile<\/strong>, which\nis more than Scrum<\/li>
Delivery<\/strong> focuses\non outcome, delivering value<\/li>
Lead<\/strong>\npositions it as a Leadership role, rightfully so. <\/li><\/ul>\n\n\n\n
(Of course,\nthis should not be mistaken to traditional Delivery Manager role. Autonomy cannot\nbe created by command-control leadership style, it needs to be\nfacilitative\/servant leadership approaches) <\/p>\n\n\n\n
So, is\nit time to reposition and change the Scrum Master name\/role to Agile Delivery Lead?\n<\/strong><\/p>\n\n\n\n
I rest my\ncase. Over to the juries. <\/p>\n","post_title":"Is it time to change the Scrum Master?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"is-it-time-to-change-the-scrum-master","to_ping":"","pinged":"","post_modified":"2024-01-29 15:12:14","post_modified_gmt":"2024-01-29 15:12:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18486","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 7 Previous 1 2 3 … 7 Next

Business Agility

Business Agility

CHOW #296: Backlog Blinkers

by Anantha Natarajan
May 29, 2022

Business Agility

Trend log, no backlog

by Anantha Natarajan
May 29, 2022

Agile

Three Track Lean-Agile Development: Part 3 – Solution Space

by Dr. Krishna Prasad
April 22, 2022

Agile

Team Working Agreement – Necessity or Nice to Have?

by Milind Rumade
April 3, 2022

Business Agility

Transform your organization like you would make Congee

by Shiv Sivaguru
February 19, 2022

Agile

To or Not-To Agile – An Experience Report

by Santhana Krishnan G
November 1, 2021

Agile

Agility Crossword

by Paramu Kurumathur
August 30, 2021

Agile

My WIP Days

by Sairam
July 4, 2021

Agile

Is Dependency a real Challenge? Are we learning?

by Sairam
March 26, 2021

Agile

Is it time to change the Scrum Master?

by Vishu
March 20, 2021

Page 2 of 7 Previous 1 2 3 … 7 Next

PM Power Consulting helps organizations achieve agility in design and delivery of software and services.

Our Offerings

Execution Excellence

Leadership Development

Organizational Excellence

About Us

Blog

Podcasts

Contact

Experts

© 2025

PM Power Consulting

Linkedin Facebook Youtube

Search for:

Rhythm & Cadence<\/h3>\n\n\n\nSecondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\nSecondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\nSecondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\nSecondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\nSecondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\nSecondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\nSecondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\nSecondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\nSecondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\nSecondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\nSecondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n

Rhythm & Cadence<\/h3>\n\n\n\n
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in. <\/p>\n\n\n\n