S Vasudev

<\/p>\n\n\n\n

<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

<\/p>\n\n\n\n

Page 2 of 6 Previous 1 2 3 … 6 Next

Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Page 2 of 6 Previous 1 2 3 … 6 Next

Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n

Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Image courtesy: Mykl Roventine at\u00a0https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
One of the challenges typically faced by the teams adopting scrum is not being able to focus on their work without interrupts. I was reminded of this by the recent blog<\/a> from my colleague JV<\/a>, where he mentions \u201cToo many \/ too much time with Agile meetings\u201d. Interrupts add to that feeling\/sense of the lack of time. This may be acute for the members who have more experience and are subject matter experts. Scrum teams are expected to swarm and that is beneficial, but at times there can be a lot of buzz, with people being busy and showing less progress on the work.<\/p>\n\n\n\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
What has\nbeen your experience? Would like to hear from you.<\/p>\n","post_title":"CHOW #263 - Should we add a buffer to estimates? When?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-263-should-we-add-a-buffer-to-estimates-when","to_ping":"","pinged":"","post_modified":"2024-01-29 14:30:53","post_modified_gmt":"2024-01-29 14:30:53","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19105","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19100,"post_author":"26","post_date":"2021-09-06 00:07:11","post_date_gmt":"2021-09-05 18:37:11","post_content":"\n
One of the challenges typically faced by the teams adopting scrum is not being able to focus on their work without interrupts. I was reminded of this by the recent blog<\/a> from my colleague JV<\/a>, where he mentions \u201cToo many \/ too much time with Agile meetings\u201d. Interrupts add to that feeling\/sense of the lack of time. This may be acute for the members who have more experience and are subject matter experts. Scrum teams are expected to swarm and that is beneficial, but at times there can be a lot of buzz, with people being busy and showing less progress on the work.<\/p>\n\n\n\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Looks like a good topic for a blog, may write one in the near future.<\/p>\n\n\n\n
What has\nbeen your experience? Would like to hear from you.<\/p>\n","post_title":"CHOW #263 - Should we add a buffer to estimates? When?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-263-should-we-add-a-buffer-to-estimates-when","to_ping":"","pinged":"","post_modified":"2024-01-29 14:30:53","post_modified_gmt":"2024-01-29 14:30:53","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19105","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19100,"post_author":"26","post_date":"2021-09-06 00:07:11","post_date_gmt":"2021-09-05 18:37:11","post_content":"\n
One of the challenges typically faced by the teams adopting scrum is not being able to focus on their work without interrupts. I was reminded of this by the recent blog<\/a> from my colleague JV<\/a>, where he mentions \u201cToo many \/ too much time with Agile meetings\u201d. Interrupts add to that feeling\/sense of the lack of time. This may be acute for the members who have more experience and are subject matter experts. Scrum teams are expected to swarm and that is beneficial, but at times there can be a lot of buzz, with people being busy and showing less progress on the work.<\/p>\n\n\n\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
On \"buffers not done in Agile\" , it is true otherwise too. Do look up Critical Chain<\/a>, which provides a good approach for buffers and covers it in depth.<\/p>\n\n\n\n
Looks like a good topic for a blog, may write one in the near future.<\/p>\n\n\n\n
What has\nbeen your experience? Would like to hear from you.<\/p>\n","post_title":"CHOW #263 - Should we add a buffer to estimates? When?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-263-should-we-add-a-buffer-to-estimates-when","to_ping":"","pinged":"","post_modified":"2024-01-29 14:30:53","post_modified_gmt":"2024-01-29 14:30:53","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19105","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19100,"post_author":"26","post_date":"2021-09-06 00:07:11","post_date_gmt":"2021-09-05 18:37:11","post_content":"\n
One of the challenges typically faced by the teams adopting scrum is not being able to focus on their work without interrupts. I was reminded of this by the recent blog<\/a> from my colleague JV<\/a>, where he mentions \u201cToo many \/ too much time with Agile meetings\u201d. Interrupts add to that feeling\/sense of the lack of time. This may be acute for the members who have more experience and are subject matter experts. Scrum teams are expected to swarm and that is beneficial, but at times there can be a lot of buzz, with people being busy and showing less progress on the work.<\/p>\n\n\n\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
It is prudent to add buffer at a higher level, like say at team member. Leave some unallocated hours, recommend single digits percentage. In this case the buffer will be used only when uncertainty manifests or unforeseen events occurs in a task. <\/p>\n\n\n\n
On \"buffers not done in Agile\" , it is true otherwise too. Do look up Critical Chain<\/a>, which provides a good approach for buffers and covers it in depth.<\/p>\n\n\n\n
Looks like a good topic for a blog, may write one in the near future.<\/p>\n\n\n\n
What has\nbeen your experience? Would like to hear from you.<\/p>\n","post_title":"CHOW #263 - Should we add a buffer to estimates? When?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-263-should-we-add-a-buffer-to-estimates-when","to_ping":"","pinged":"","post_modified":"2024-01-29 14:30:53","post_modified_gmt":"2024-01-29 14:30:53","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19105","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19100,"post_author":"26","post_date":"2021-09-06 00:07:11","post_date_gmt":"2021-09-05 18:37:11","post_content":"\n
One of the challenges typically faced by the teams adopting scrum is not being able to focus on their work without interrupts. I was reminded of this by the recent blog<\/a> from my colleague JV<\/a>, where he mentions \u201cToo many \/ too much time with Agile meetings\u201d. Interrupts add to that feeling\/sense of the lack of time. This may be acute for the members who have more experience and are subject matter experts. Scrum teams are expected to swarm and that is beneficial, but at times there can be a lot of buzz, with people being busy and showing less progress on the work.<\/p>\n\n\n\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Once a\nbuffer is added, it gets hidden\/obscure and the tasks tend to take up the estimated\neffort including the buffer. Look at it the other way, if you have added buffer\nto all tasks then at least two thirds of the tasks should complete in less\neffort than estimated, which is never the case.<\/p>\n\n\n\n
It is prudent to add buffer at a higher level, like say at team member. Leave some unallocated hours, recommend single digits percentage. In this case the buffer will be used only when uncertainty manifests or unforeseen events occurs in a task. <\/p>\n\n\n\n
On \"buffers not done in Agile\" , it is true otherwise too. Do look up Critical Chain<\/a>, which provides a good approach for buffers and covers it in depth.<\/p>\n\n\n\n
Looks like a good topic for a blog, may write one in the near future.<\/p>\n\n\n\n
What has\nbeen your experience? Would like to hear from you.<\/p>\n","post_title":"CHOW #263 - Should we add a buffer to estimates? When?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-263-should-we-add-a-buffer-to-estimates-when","to_ping":"","pinged":"","post_modified":"2024-01-29 14:30:53","post_modified_gmt":"2024-01-29 14:30:53","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19105","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19100,"post_author":"26","post_date":"2021-09-06 00:07:11","post_date_gmt":"2021-09-05 18:37:11","post_content":"\n
One of the challenges typically faced by the teams adopting scrum is not being able to focus on their work without interrupts. I was reminded of this by the recent blog<\/a> from my colleague JV<\/a>, where he mentions \u201cToo many \/ too much time with Agile meetings\u201d. Interrupts add to that feeling\/sense of the lack of time. This may be acute for the members who have more experience and are subject matter experts. Scrum teams are expected to swarm and that is beneficial, but at times there can be a lot of buzz, with people being busy and showing less progress on the work.<\/p>\n\n\n\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
One key\nmessage is that buffers are for dealing with uncertainty and unforeseen issues.\nThese do not manifest 100% of the time, it would typically manifest in say about\none third of the tasks. <\/p>\n\n\n\n
Once a\nbuffer is added, it gets hidden\/obscure and the tasks tend to take up the estimated\neffort including the buffer. Look at it the other way, if you have added buffer\nto all tasks then at least two thirds of the tasks should complete in less\neffort than estimated, which is never the case.<\/p>\n\n\n\n
It is prudent to add buffer at a higher level, like say at team member. Leave some unallocated hours, recommend single digits percentage. In this case the buffer will be used only when uncertainty manifests or unforeseen events occurs in a task. <\/p>\n\n\n\n
On \"buffers not done in Agile\" , it is true otherwise too. Do look up Critical Chain<\/a>, which provides a good approach for buffers and covers it in depth.<\/p>\n\n\n\n
Looks like a good topic for a blog, may write one in the near future.<\/p>\n\n\n\n
What has\nbeen your experience? Would like to hear from you.<\/p>\n","post_title":"CHOW #263 - Should we add a buffer to estimates? When?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-263-should-we-add-a-buffer-to-estimates-when","to_ping":"","pinged":"","post_modified":"2024-01-29 14:30:53","post_modified_gmt":"2024-01-29 14:30:53","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19105","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19100,"post_author":"26","post_date":"2021-09-06 00:07:11","post_date_gmt":"2021-09-05 18:37:11","post_content":"\n
One of the challenges typically faced by the teams adopting scrum is not being able to focus on their work without interrupts. I was reminded of this by the recent blog<\/a> from my colleague JV<\/a>, where he mentions \u201cToo many \/ too much time with Agile meetings\u201d. Interrupts add to that feeling\/sense of the lack of time. This may be acute for the members who have more experience and are subject matter experts. Scrum teams are expected to swarm and that is beneficial, but at times there can be a lot of buzz, with people being busy and showing less progress on the work.<\/p>\n\n\n\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
I would do a session with the team and elicit why they add a buffer and how it gets used or consumed. It will be an interactive session wherein I will help\/guide the team get a good feel for what is the right thing to do.<\/p>\n\n\n\n
One key\nmessage is that buffers are for dealing with uncertainty and unforeseen issues.\nThese do not manifest 100% of the time, it would typically manifest in say about\none third of the tasks. <\/p>\n\n\n\n
Once a\nbuffer is added, it gets hidden\/obscure and the tasks tend to take up the estimated\neffort including the buffer. Look at it the other way, if you have added buffer\nto all tasks then at least two thirds of the tasks should complete in less\neffort than estimated, which is never the case.<\/p>\n\n\n\n
It is prudent to add buffer at a higher level, like say at team member. Leave some unallocated hours, recommend single digits percentage. In this case the buffer will be used only when uncertainty manifests or unforeseen events occurs in a task. <\/p>\n\n\n\n
On \"buffers not done in Agile\" , it is true otherwise too. Do look up Critical Chain<\/a>, which provides a good approach for buffers and covers it in depth.<\/p>\n\n\n\n
Looks like a good topic for a blog, may write one in the near future.<\/p>\n\n\n\n
What has\nbeen your experience? Would like to hear from you.<\/p>\n","post_title":"CHOW #263 - Should we add a buffer to estimates? When?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-263-should-we-add-a-buffer-to-estimates-when","to_ping":"","pinged":"","post_modified":"2024-01-29 14:30:53","post_modified_gmt":"2024-01-29 14:30:53","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19105","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19100,"post_author":"26","post_date":"2021-09-06 00:07:11","post_date_gmt":"2021-09-05 18:37:11","post_content":"\n
One of the challenges typically faced by the teams adopting scrum is not being able to focus on their work without interrupts. I was reminded of this by the recent blog<\/a> from my colleague JV<\/a>, where he mentions \u201cToo many \/ too much time with Agile meetings\u201d. Interrupts add to that feeling\/sense of the lack of time. This may be acute for the members who have more experience and are subject matter experts. Scrum teams are expected to swarm and that is beneficial, but at times there can be a lot of buzz, with people being busy and showing less progress on the work.<\/p>\n\n\n\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
This is an often-encountered\nsituation in some teams, that do detailed task estimates and match with their\ncapacity during the sprint planning.<\/p>\n\n\n\n
I would do a session with the team and elicit why they add a buffer and how it gets used or consumed. It will be an interactive session wherein I will help\/guide the team get a good feel for what is the right thing to do.<\/p>\n\n\n\n
One key\nmessage is that buffers are for dealing with uncertainty and unforeseen issues.\nThese do not manifest 100% of the time, it would typically manifest in say about\none third of the tasks. <\/p>\n\n\n\n
Once a\nbuffer is added, it gets hidden\/obscure and the tasks tend to take up the estimated\neffort including the buffer. Look at it the other way, if you have added buffer\nto all tasks then at least two thirds of the tasks should complete in less\neffort than estimated, which is never the case.<\/p>\n\n\n\n
It is prudent to add buffer at a higher level, like say at team member. Leave some unallocated hours, recommend single digits percentage. In this case the buffer will be used only when uncertainty manifests or unforeseen events occurs in a task. <\/p>\n\n\n\n
On \"buffers not done in Agile\" , it is true otherwise too. Do look up Critical Chain<\/a>, which provides a good approach for buffers and covers it in depth.<\/p>\n\n\n\n
Looks like a good topic for a blog, may write one in the near future.<\/p>\n\n\n\n
What has\nbeen your experience? Would like to hear from you.<\/p>\n","post_title":"CHOW #263 - Should we add a buffer to estimates? When?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-263-should-we-add-a-buffer-to-estimates-when","to_ping":"","pinged":"","post_modified":"2024-01-29 14:30:53","post_modified_gmt":"2024-01-29 14:30:53","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19105","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19100,"post_author":"26","post_date":"2021-09-06 00:07:11","post_date_gmt":"2021-09-05 18:37:11","post_content":"\n
One of the challenges typically faced by the teams adopting scrum is not being able to focus on their work without interrupts. I was reminded of this by the recent blog<\/a> from my colleague JV<\/a>, where he mentions \u201cToo many \/ too much time with Agile meetings\u201d. Interrupts add to that feeling\/sense of the lack of time. This may be acute for the members who have more experience and are subject matter experts. Scrum teams are expected to swarm and that is beneficial, but at times there can be a lot of buzz, with people being busy and showing less progress on the work.<\/p>\n\n\n\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
This is an often-encountered\nsituation in some teams, that do detailed task estimates and match with their\ncapacity during the sprint planning.<\/p>\n\n\n\n
I would do a session with the team and elicit why they add a buffer and how it gets used or consumed. It will be an interactive session wherein I will help\/guide the team get a good feel for what is the right thing to do.<\/p>\n\n\n\n
One key\nmessage is that buffers are for dealing with uncertainty and unforeseen issues.\nThese do not manifest 100% of the time, it would typically manifest in say about\none third of the tasks. <\/p>\n\n\n\n
Once a\nbuffer is added, it gets hidden\/obscure and the tasks tend to take up the estimated\neffort including the buffer. Look at it the other way, if you have added buffer\nto all tasks then at least two thirds of the tasks should complete in less\neffort than estimated, which is never the case.<\/p>\n\n\n\n
It is prudent to add buffer at a higher level, like say at team member. Leave some unallocated hours, recommend single digits percentage. In this case the buffer will be used only when uncertainty manifests or unforeseen events occurs in a task. <\/p>\n\n\n\n
On \"buffers not done in Agile\" , it is true otherwise too. Do look up Critical Chain<\/a>, which provides a good approach for buffers and covers it in depth.<\/p>\n\n\n\n
Looks like a good topic for a blog, may write one in the near future.<\/p>\n\n\n\n
What has\nbeen your experience? Would like to hear from you.<\/p>\n","post_title":"CHOW #263 - Should we add a buffer to estimates? When?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-263-should-we-add-a-buffer-to-estimates-when","to_ping":"","pinged":"","post_modified":"2024-01-29 14:30:53","post_modified_gmt":"2024-01-29 14:30:53","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19105","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19100,"post_author":"26","post_date":"2021-09-06 00:07:11","post_date_gmt":"2021-09-05 18:37:11","post_content":"\n
One of the challenges typically faced by the teams adopting scrum is not being able to focus on their work without interrupts. I was reminded of this by the recent blog<\/a> from my colleague JV<\/a>, where he mentions \u201cToo many \/ too much time with Agile meetings\u201d. Interrupts add to that feeling\/sense of the lack of time. This may be acute for the members who have more experience and are subject matter experts. Scrum teams are expected to swarm and that is beneficial, but at times there can be a lot of buzz, with people being busy and showing less progress on the work.<\/p>\n\n\n\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Suhas calls\nyou up, you have recently started coaching the team. He asks you about adding\nbuffers and shares Pratik\u2019s inputs. What will be your response?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
This is an often-encountered\nsituation in some teams, that do detailed task estimates and match with their\ncapacity during the sprint planning.<\/p>\n\n\n\n
I would do a session with the team and elicit why they add a buffer and how it gets used or consumed. It will be an interactive session wherein I will help\/guide the team get a good feel for what is the right thing to do.<\/p>\n\n\n\n
One key\nmessage is that buffers are for dealing with uncertainty and unforeseen issues.\nThese do not manifest 100% of the time, it would typically manifest in say about\none third of the tasks. <\/p>\n\n\n\n
Once a\nbuffer is added, it gets hidden\/obscure and the tasks tend to take up the estimated\neffort including the buffer. Look at it the other way, if you have added buffer\nto all tasks then at least two thirds of the tasks should complete in less\neffort than estimated, which is never the case.<\/p>\n\n\n\n
It is prudent to add buffer at a higher level, like say at team member. Leave some unallocated hours, recommend single digits percentage. In this case the buffer will be used only when uncertainty manifests or unforeseen events occurs in a task. <\/p>\n\n\n\n
On \"buffers not done in Agile\" , it is true otherwise too. Do look up Critical Chain<\/a>, which provides a good approach for buffers and covers it in depth.<\/p>\n\n\n\n
Looks like a good topic for a blog, may write one in the near future.<\/p>\n\n\n\n
What has\nbeen your experience? Would like to hear from you.<\/p>\n","post_title":"CHOW #263 - Should we add a buffer to estimates? When?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-263-should-we-add-a-buffer-to-estimates-when","to_ping":"","pinged":"","post_modified":"2024-01-29 14:30:53","post_modified_gmt":"2024-01-29 14:30:53","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19105","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19100,"post_author":"26","post_date":"2021-09-06 00:07:11","post_date_gmt":"2021-09-05 18:37:11","post_content":"\n
One of the challenges typically faced by the teams adopting scrum is not being able to focus on their work without interrupts. I was reminded of this by the recent blog<\/a> from my colleague JV<\/a>, where he mentions \u201cToo many \/ too much time with Agile meetings\u201d. Interrupts add to that feeling\/sense of the lack of time. This may be acute for the members who have more experience and are subject matter experts. Scrum teams are expected to swarm and that is beneficial, but at times there can be a lot of buzz, with people being busy and showing less progress on the work.<\/p>\n\n\n\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Pratik\nmentions to Suhas that he learned from Prerana that the team members are adding\nbuffers to their task estimate during Sprint Planning. He tells Suhas that is\nnot correct to add buffers to tasks estimates, it is not done in Agile.<\/p>\n\n\n\n
Suhas calls\nyou up, you have recently started coaching the team. He asks you about adding\nbuffers and shares Pratik\u2019s inputs. What will be your response?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
This is an often-encountered\nsituation in some teams, that do detailed task estimates and match with their\ncapacity during the sprint planning.<\/p>\n\n\n\n
I would do a session with the team and elicit why they add a buffer and how it gets used or consumed. It will be an interactive session wherein I will help\/guide the team get a good feel for what is the right thing to do.<\/p>\n\n\n\n
One key\nmessage is that buffers are for dealing with uncertainty and unforeseen issues.\nThese do not manifest 100% of the time, it would typically manifest in say about\none third of the tasks. <\/p>\n\n\n\n
Once a\nbuffer is added, it gets hidden\/obscure and the tasks tend to take up the estimated\neffort including the buffer. Look at it the other way, if you have added buffer\nto all tasks then at least two thirds of the tasks should complete in less\neffort than estimated, which is never the case.<\/p>\n\n\n\n
It is prudent to add buffer at a higher level, like say at team member. Leave some unallocated hours, recommend single digits percentage. In this case the buffer will be used only when uncertainty manifests or unforeseen events occurs in a task. <\/p>\n\n\n\n
On \"buffers not done in Agile\" , it is true otherwise too. Do look up Critical Chain<\/a>, which provides a good approach for buffers and covers it in depth.<\/p>\n\n\n\n
Looks like a good topic for a blog, may write one in the near future.<\/p>\n\n\n\n
What has\nbeen your experience? Would like to hear from you.<\/p>\n","post_title":"CHOW #263 - Should we add a buffer to estimates? When?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-263-should-we-add-a-buffer-to-estimates-when","to_ping":"","pinged":"","post_modified":"2024-01-29 14:30:53","post_modified_gmt":"2024-01-29 14:30:53","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19105","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19100,"post_author":"26","post_date":"2021-09-06 00:07:11","post_date_gmt":"2021-09-05 18:37:11","post_content":"\n
One of the challenges typically faced by the teams adopting scrum is not being able to focus on their work without interrupts. I was reminded of this by the recent blog<\/a> from my colleague JV<\/a>, where he mentions \u201cToo many \/ too much time with Agile meetings\u201d. Interrupts add to that feeling\/sense of the lack of time. This may be acute for the members who have more experience and are subject matter experts. Scrum teams are expected to swarm and that is beneficial, but at times there can be a lot of buzz, with people being busy and showing less progress on the work.<\/p>\n\n\n\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

\n
Pratik is a\nnew member in a Scrum team; he has come from another organization which had adopted\nAgile much before the current one. As a new member he is having a 1:1 catch up\nwith all the other team members, this is to get familiar with the team, in\nthese WFH times. After one such catch-up with a team member Prerana he calls up\nthe Scrum Master Suhas.<\/p>\n\n\n\n
Pratik\nmentions to Suhas that he learned from Prerana that the team members are adding\nbuffers to their task estimate during Sprint Planning. He tells Suhas that is\nnot correct to add buffers to tasks estimates, it is not done in Agile.<\/p>\n\n\n\n
Suhas calls\nyou up, you have recently started coaching the team. He asks you about adding\nbuffers and shares Pratik\u2019s inputs. What will be your response?<\/p>\n\n\n\n
Suggested Solution:<\/strong><\/p>\n\n\n\n
This is an often-encountered\nsituation in some teams, that do detailed task estimates and match with their\ncapacity during the sprint planning.<\/p>\n\n\n\n
I would do a session with the team and elicit why they add a buffer and how it gets used or consumed. It will be an interactive session wherein I will help\/guide the team get a good feel for what is the right thing to do.<\/p>\n\n\n\n
One key\nmessage is that buffers are for dealing with uncertainty and unforeseen issues.\nThese do not manifest 100% of the time, it would typically manifest in say about\none third of the tasks. <\/p>\n\n\n\n
Once a\nbuffer is added, it gets hidden\/obscure and the tasks tend to take up the estimated\neffort including the buffer. Look at it the other way, if you have added buffer\nto all tasks then at least two thirds of the tasks should complete in less\neffort than estimated, which is never the case.<\/p>\n\n\n\n
It is prudent to add buffer at a higher level, like say at team member. Leave some unallocated hours, recommend single digits percentage. In this case the buffer will be used only when uncertainty manifests or unforeseen events occurs in a task. <\/p>\n\n\n\n
On \"buffers not done in Agile\" , it is true otherwise too. Do look up Critical Chain<\/a>, which provides a good approach for buffers and covers it in depth.<\/p>\n\n\n\n
Looks like a good topic for a blog, may write one in the near future.<\/p>\n\n\n\n
What has\nbeen your experience? Would like to hear from you.<\/p>\n","post_title":"CHOW #263 - Should we add a buffer to estimates? When?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-263-should-we-add-a-buffer-to-estimates-when","to_ping":"","pinged":"","post_modified":"2024-01-29 14:30:53","post_modified_gmt":"2024-01-29 14:30:53","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19105","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":19100,"post_author":"26","post_date":"2021-09-06 00:07:11","post_date_gmt":"2021-09-05 18:37:11","post_content":"\n
One of the challenges typically faced by the teams adopting scrum is not being able to focus on their work without interrupts. I was reminded of this by the recent blog<\/a> from my colleague JV<\/a>, where he mentions \u201cToo many \/ too much time with Agile meetings\u201d. Interrupts add to that feeling\/sense of the lack of time. This may be acute for the members who have more experience and are subject matter experts. Scrum teams are expected to swarm and that is beneficial, but at times there can be a lot of buzz, with people being busy and showing less progress on the work.<\/p>\n\n\n\n
The above\nhas come up frequently in my role as a coach, brought to the fore by the team\nmembers, Scrum Masters and Leaders at different times. It gets highlighted\nduring retrospectives at times. <\/p>\n\n\n\n
I will tell\na real-life story from before the Agile days, something that I experienced\nwhich drives home the point and helps the challenged members come up with a\nsolution.<\/p>\n\n\n\n
The story<\/h2>\n\n\n\n
Years back\nthere was a set of work items related to a flagship product that needed to be\ncompleted, it was pending for a long time. Vijay the architect offered to get\nthe work items done in a couple of months, if he could get a few freshers to\nwork with him. This was just after a campus recruitment drive and a team comprising\nof Vijay and four freshers was formed to have a go at it. It was a wonderful\ninduction exercise too.<\/p>\n\n\n\n
In the\nfirst review after a fortnight, we saw that the new joinees had made good\nprogress on their tasks, whereas Vijay was lagging on his tasks. Vijay was\nconstantly being interrupted by the enthusiastic team members and was unable to\nfocus on his work. He shared the same in the review meet.<\/p>\n\n\n\n
The team\nwas quick to understand this. One of the team members, Sangeeta came up with\nthe idea to not disturb Vijay till lunch time. They decided to collate their\nqueries and approach him only after the lunch break. This sounded like a good\nidea and was adopted. It had an amazing impact and also provided Vijay and the\nteam with a very valuable lesson.<\/p>\n\n\n\n
Vijay set\naside a few hours after the lunch to address the team members\u2019 questions and\nlook at their issues. He was pleasantly surprised to discover that that he\nneeded just half the time that he had spent before with the team. He could get\nback to his work faster and was able to make good progress. <\/p>\n\n\n\n
In the next\nreview meet the progress was impressive. We figured the few things that were\nhappening differently when a team member had a query or a block:<\/p>\n\n\n\n
Initial\nresponse would be to wait till Vijay is available at lunch break. The wait\nbeing long would push them to try out a few things and often they could resolve\/progress<\/li>
Sometimes\ntwo of them would get together and lament on the wait, in the process they\nwould discuss the issues and often work out a resolution together<\/li>
Sometimes\nthey would stop work and pick up a different work item and progress on that.<\/li>
Every\nresolution they made, boosted their learning and confidence<\/li><\/ul>\n\n\n\n
A very\nsimple story which has never failed to have the desired impact whenever I\ncoached many other\nteams facing similar bandwidth issues. One realizes that having easy access to\na Subject Matter Expert can be detrimental, if the SME and team member are not\nmindful of the impact of the interrupts and multitasking. <\/p>\n\n\n\n
I also walk\nthem through or refer them to the Critical Chain method<\/a> which talks of multitasking and a\nfew other related concepts.<\/p>\n\n\n\n
Outcome<\/h2>\n\n\n\n
The teams\nhave come up with different approaches to get over this issue and get focused\nand uninterrupted time to accomplish their tasks.<\/p>\n\n\n\n
The most\ncommon is to have Do Not Disturb times per team or per individual.<\/p>\n\n\n\n
More\nevolved solutions are teams leverage the collaboration tools, posting their\nqueries in them. The team members look into it at their chosen time and\nrespond.<\/p>\n\n\n\n
It is\nuseful that the team understands the need for Focus which is necessary to meet\nCommitments and the negative impact that interrupts and multitasking can have.\nI encourage the team to build this into their team norms\/working agreement and\nreview it periodically.<\/p>\n\n\n\n
Have you come\nacross something along the same lines? Would love to hear about your experiences.\n<\/p>\n\n\n\n
Vasu<\/p>\n\n\n\n
\"Focus\" by toolstop is licensed with CC BY 2.0. To view a copy of this license, visit https:\/\/creativecommons.org\/licenses\/by\/2.0\/<\/p>\n","post_title":"A story to help with sustaining focus","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"a-story-to-help-with-sustaining-focus","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:06","post_modified_gmt":"2024-01-29 14:31:06","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=19100","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18629,"post_author":"26","post_date":"2021-05-01 19:01:10","post_date_gmt":"2021-05-01 13:31:10","post_content":"\n
Ashok <\/span>is the Scrum Master for the Black Hawks team. The team has completed the 5th Sprint with him as the Scrum Master and also the Sprint Review and Sprint Retrospective. The team was not able to close a high priority story due to a technical impediment. The team is not happy about this outcome, it so happens that this is a second instance of this happening. Earlier instance was before Ashok came in as the Scrum Master.

The impediment did come up in the daily stand-up and it seemed to Ashok that it will get resolved. There was no request for help or any offer to help and he did not think much of it. Ashok was under the impression that if team members need or can help, they will ask or reach out for it.

In hindsight and based on the retrospective, Ashok learns that the required skills to overcome the technical impediment was present within the team, but it was not leveraged. It was the same in the past too when a similar incident happened. The team members are focused on their stories and tasks that they planned for in the Sprint, and do not venture beyond that. <\/p>\n\n\n\n
Clearly swarming is lacking, the team has taken a retro action item to improve swarming. He sets up a meeting with you (coach) to go over this. What would be your approach in the meeting?<\/p>\n\n\n\n
\n\n\n\n
Ashok has moved to this team recently, but has had good experience as a Scrum Master.

As a coach, I will ask him if he had faced a similar situation in the past and how he went about it. This will be a good starting point, as what he has done in the past may or may not apply. Some tweaking would be needed based on the team context.
I will then ask questions to understand the team context, which in turn will make him think and assess or review the team context. Expect an approach to naturally evolve from him after this, which I can review with him.

In this instance, what emerged was that Black Hawks did pretty detailed Sprint planning, drilling down on the tasks, compared to the team he was earlier working with. He felt that though all team members participated in the planning, it narrowed the focus of the team members on to their stories and tasks.

Ashok had recently done an Agile Maturity Assessment for his earlier team. One of assessment aspects was related to Sprint planning. It tried to assess what the team members were \"committing to\" at the end of Sprint planning:
\u2013 were the team members committing to their individual stories and tasks
or
- were they committing to the Sprint goal with the understanding that they may need swarm.

I jogged his memory on this, he liked it and decided to leverage this, posing this as a question at the conclusion of the next Sprint Planning. The answer from the team was the Sprint goal. He then asked team members to provide an outlook upfront, if they were likely to encounter any issues and need help.
This step helped in setting the right context in the team, shifting the team members focus to the sprint goal over their individual tasks and also anticipate the course of the sprint.
Setting the context was the first step. He observed the team keenly thru the sprint, nudged and guided the team as needed. The team was able to swarm and perform better subsequently.<\/p>\n\n\n\n
Would like to hear your experiences.<\/p>\n\n\n\n
Photo by Papaioannou Kostas on Unsplash<\/pre>\n","post_title":"CHOW #245- Swarming in teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-245-swarming-in-teams","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:19","post_modified_gmt":"2024-01-29 14:31:19","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18629","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":18623,"post_author":"26","post_date":"2021-05-01 12:07:56","post_date_gmt":"2021-05-01 06:37:56","post_content":"\n
Today, in this blog, I share a story on a few steps that improved transparency in the team. Which in turn enhanced the ownership and collaboration. In my last blog tweaks in traditional approach...<\/a> I shared how individual reflection is key to staying on the course and how Agile helps in that. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learnings from the traditional approaches, for use in the agile context. That is another motivation for sharing the same here.<\/p>\n\n\n\n
This is the second blog in the series explaining how insights gained and lessons learned through hard knocks and serendipity in traditional ways of software development are incorporated and institutionalized in the Agile way. Over a period of time, I found that agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised it, to make a very nice comprehensive package. <\/p>\n\n\n\n
The surprise learning<\/h4>\n\n\n\n
I had a situation where one of the project managers Santosh <\/span>was in need of a developer, to enhance a feature quickly. Luckily, in course of our review meeting with all the project managers, Vidya <\/span>another project manager, offered to loan Vijay<\/span>, a developer in her team for a few weeks. It was an offer that Santosh eagerly accepted. Vidya added a caveat - that though skilled, he is focused and dedicated to his tasks and not flexible nor steps out of his role.

After a few weeks of this arrangement, we were in the review meet with the project managers. Santosh and his team were able to make good progress on their feature. He thanked Vidya for the timely help by loaning Vijay. He added that Vijay is quite a helpful person and proactively stepped outside his role to resolve a technical issue, in a feature being done by their tech lead. This was a surprise for me and more so for Vidya who almost fell out of her chair. What we had just heard is that Vijay was flexible and steps out his role when the need be! Santosh was happy and did not dwell on it, but Vidya and myself were intrigued, by this welcome change in Vijay.

It was but natural for us to try figure this out and we set about to do that. I had the practice of joining their team meetings as an observer, infrequently. I leveraged the same, to try and observe what was different between the teams of Santosh and Vidya. Eventually, it was just the matter of how the project review was being done.

Vidya being a task-oriented person, often in a hurry, would go to the desk of the team members and quickly get an update on their progress, at the start of every week. The team members were used to this, though initially they would be intimidated. Vidya would consolidate the info and then present it in their team meeting and figure out the next steps.

Santosh on the other hand, would get all the team members together and ask them to share their updates - with others listening in. There were murmurs of this meet being long initially, but over a period of time they got used to it, but not sure if they had realized the benefits. It so happened that in one of these meetings, Vijay volunteered to help.<\/p>\n\n\n\n
What made the difference? <\/h4>\n\n\n\n
It was the transparency of progress, challenges faced as well as how had they tried to overcome them. Vijay had developed a T shaped awareness, if I may say so, of the work. He was clued on the progress and the challenges in the other features. At one point, he knew that help was needed and offered it.

If he had been in Vidya\u2019s team \u2013 Vidya would have reached out to Vijay for help and possibly Vijay would not be very aware of the issue, its intricacies and the genuine challenges faced. He would be inclined to decline, as it could likely appear to him as something not managed well.

The way Vidya was reviewing the progress, reduced the possibility of the team members being aware of the others work, even at a high level. The approach Santosh adopted helped in the team members being aware of the same, awareness is the precursor for any related response or action.<\/p>\n\n\n\n
It was quite an eye opener for all of us, once I shared my observations Vidya was sort of convinced and decided to change her approach. She was able to see the impact of the same in her teams, quite quickly.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Transparency is one of the pillars of Scrum, one of the popular Agile frameworks. Inspection and Adaptation being the other two. We had to make effort to bring is transparency in the traditional approach, which helped in enhancing team collaboration. In Agile, various artefacts like the task board, burndown charts and events like the daily stand-up weaves in this transparency. Once that is there it is natural to inspect, which brings in a shared awareness in the team. Awareness is the stepping stone for the team to adapt to the situation to reach the set goal.

Often at start of the Agile journey teams tend to focus on their stories and tasks. All of the agile artefacts and events do not have the intended impact. At such times I share this story, which helps them in understanding the principles. It then helps them to move towards better collaboration.

I have also share this story with leaders more conversant with the traditional approach. Once they understand the impact of transparency and how Agile takes it to another level. They are appreciate the Agile approach and are more supportive of their team.

Would like to hear your thoughts on this, please share your views and comments. <\/p>\n\n\n\n
Photo by Smartworks Coworking on Unsplash<\/small><\/pre>\n","post_title":"Insights from the traditional ways... Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"insights-from-the-traditional-ways-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:31:34","post_modified_gmt":"2024-01-29 14:31:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18623","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17959,"post_author":"26","post_date":"2021-01-02 07:12:24","post_date_gmt":"2021-01-02 01:42:24","post_content":"\n
You are coaching a team based in another location. You have made good progress with Kathy (Scrum<\/a>\u00a0Master), Mark (Product Owner<\/a>) and the team MasterMinds. When you interact with the team after the Thanksgiving break, you notice that the team has started doing their daily stand-up over email.

You learn that Kathy left on vacation a few days before the holidays, informally asking David (Team member) to play the role of Scrum Master. On the day before the holidays some were leaving early so Mark suggested that they send their update by email. The regular stand-up was scheduled towards the end of their workday. When they were back after holidays, they did the same as all team members were not back at work.

Then one of the team suggested to continue this, as it is working well and the team agreed.

What would you, as a coach, do in this situation?

Solution:
One piece of information that is not mentioned above is the duration of their Agile adoption. As the coach is in the picture, one may surmise that they are progressing on their Agile journey.
Another relevant information is that the team was well knit with their cubicles located close to each other\u2019s.

Obviously, the coach should make them understand the principles behind the practice and help them internalize the same. At the least<\/p>\n\n\n\n
\n
Face to face is the most efficient way of communication.<\/li>\n\n\n\n
Daily stand-up is a daily planning meet and not just for updating progress.<\/li>\n<\/ul>\n\n\n\n
The coach could observe for a while and highlight issues that naturally crop up OR share examples from other teams\/instances. In this case I let them continue their experiment and soon the team encountered a few issues.

First was that the updates started coming in at different times of the day, if a one sent the update late, the tendency was to stick to that same time the next day. This was a minor one.

Second was that few of the team were caught by surprise on some of the decisions taken. Two team members faced an impediment collaborated and took corrective action but overlooked its impact on others.

It became clear that if they had the daily stand-up all would be aware of the actions and its impact. The individual impacted could participate and contribute to better solution. The team learned their lesson by experimenting and such learning are long lasting.<\/p>\n\n\n\n
Photo by Libby Penner<\/a> on Unsplash<\/a>
Photo by Solen Feyissa<\/a> on Unsplash<\/a><\/p>\n","post_title":"CHOW #228 - Daily Stand-up over Email","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"daily-stand-up-over-email","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:28","post_modified_gmt":"2024-01-29 14:32:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17959","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17952,"post_author":"26","post_date":"2021-01-01 12:07:03","post_date_gmt":"2021-01-01 06:37:03","post_content":"\n
As a coach, I often reflect on how the approaches and the practices have evolved from the traditional to the Agile. I can recollect many instances and moments, when we did things differently, improvised a bit, in the traditional world. These were steps, tips, tricks that improved the effectiveness in the traditional approaches. Over a period of time, I found that Agile embodies all that we had evolved as \u201ctraditional wisdom\u201d and improvised, into a very nice comprehensive package.

In this blog I will share one such instance and contrast traditional and Agile. Hope to follow-up with a few more blogs along the same lines. I have been able to leverage the learning from the traditional approaches for Agile and that is another motivation for sharing the same here.

One of my favorite topics in the workshops on traditional project management, was tracking project progress and specifically the status update.

I would ask the participants which of the two approaches they would choose to get a status update from their team. Quiz them on why they made the choice and which would yield better results. Those were the days where the team would typically track progress on a weekly basis.<\/p>\n\n\n\n
A. The team gets together first thing on a Monday morning and each team member provides a verbal update on the progress he or she has made.<\/li><\/ul>\n\n\n\n
B. The team sends a brief update on progress by email, as they get back to work after the weekend and then get together slightly later in the day to update the progress face to face in a meeting.<\/li><\/ul>\n\n\n\n
Most would opt for Option B with some pitching for Option A. A few felt that email update to be a waste, as it may not be read, given one would be meeting soon. I would then share the gem of a learning from one of my early managers \u2013 the status update is as much for the individual as it is for the manager, it is the individual who can make a difference. For the individual to make the difference, he or she should know where they stand.

Creating and sending an update by email helps provide one, the moment of reflection<\/span>, where one is just by oneself and there is no pressure to look or sound good as in a team meeting. One may make the progress look better in the email than it is, but one knows what the \u201creal\u201d status is. If this is achieved with each individual in the team then a large part of the leader\u2019s job is done.<\/p>\n\n\n\n
It is not that one may not reflect when providing an update directly in the team meeting. There will be diligent team members who will prepare and provide an accurate picture. There will be some who may fudge a bit to look or sound good. If that is not countered, for whatever reason, there is a risk that the individual may himself start believing it and fail to make needed amends. Then there could be few who may not have a correct assessment for whatever reason and provide an inaccurate update.

The moment of reflection is key, this is where the maximum impact happens. This followed by the act of writing enhances that impact by making one aware of the situation, quickly leading to thinking of solutions. Mindfulness <\/span>practices talk about silent reflection<\/span> and journaling <\/span>and is acknowledged to be of significant help. An email status update is sort of a mini journaling <\/span>exercise.<\/p>\n\n\n\n
In the Agile world<\/h4>\n\n\n\n
Now let\u2019s look at how we do the same in Agile. Firstly, there is a sea change here due to the tracking being daily and iteration being just a few weeks. That itself brings in a lot of benefits, keeping that aside let\u2019s focus here on how the progress is tracked.

Typically, teams do a daily stand up where they share their progress. Most teams use a physical board or a tool to track the progress, and update that prior to the stand up. Quite a few teams follow the practice of updating the remaining hours in the tool they use. Updating progress in the tool before the stand-up is a good practice which enforces one to reflect <\/span>and the act of updating can be likened to journaling<\/span>.

Doing the above leads the team members towards naturally thinking of solutions to issues and planning any corrective action. With this the daily stand-up stands a good chance to turn into the daily planning meet as it is intended to be. Each of the team member is aware of where he or she stands and hence a clear outlook on how to proceed.<\/p>\n\n\n\n
Impact<\/h4>\n\n\n\n
Teams that do not update the physical board or tool may not make good progress and may miss their goals. Key is ensuring that the daily stand-up is a daily planning meet. This can happen if each team member is doing the equivalent of reflection and journaling.

As a coach I make the leader\/team aware of this, sharing the past experience from the traditional world, as articulated above, helps them grasp this quickly. Whatever approach one follows, ultimately the contribution is from the individual team members working towards a goal. Agile makes it easy by it's many practices, incremental approach; but the team member needs to be mindfully aware of where they are on a daily basis. A leader helps the team members on this journey.

Would like to hear your thoughts on this, please share your thoughts.<\/p>\n\n\n\n
Photo by ConvertKit<\/a>\non Unsplash<\/a><\/p>\n","post_title":"Tweaks in the traditional approach\u2026 Agile","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"tweaks-in-the-traditional-approach-agile","to_ping":"","pinged":"","post_modified":"2024-01-29 14:32:46","post_modified_gmt":"2024-01-29 14:32:46","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17952","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":15533,"post_author":"26","post_date":"2020-08-16 21:02:12","post_date_gmt":"2020-08-16 15:32:12","post_content":"\n
Image courtesy: Mykl Roventine at\u00a0 https:\/\/www.flickr.com\/photos\/64419960@N00\/4143699557<\/a><\/p>\n\n\n\n
Emotional Intelligence (EQ) is key for one to be successful, especially so for leaders. A person with higher EQ will respond to a situation over reacting to it. To quote Viktor E Frankl, \u201cBetween stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.\u201d In this blog I will talk about the Ladder of Inference which leverages one\u2019s EQ and strengthens it.<\/p>\n\n\n\n
Respond vs. React<\/h4>\n\n\n\n
One would have heard about counting till 10, if one is angry before they respond. Waiting for a while before you send off an angry email or a post. Ascertaining by asking questions the correct understanding of the situation, before one responds or acts.<\/p>\n\n\n\n
As an Agile coach I focus on the person being able to respond over react. I use a plethora of approaches to coach them, starting with making them aware of situations observed, where there could have been alternate responses\/outcomes. I encourage them to focus on data\/facts over going by assumptions, stress on separating the people from their ideas\/deeds. I leverage my experience and draw upon a few concepts from the Seven Habits by Steven Covey \u2013 Being Proactive, Begin with the end in mind. ...

This goes hand in hand with making them aware of EQ and its components<\/a>, as popularized by Daniel Goleman - Self-awareness, Self-Regulation, Self-Motivation, Empathy and Social Skills. Each person has to become aware of themselves and their emotions as well as be conscious of others and their emotions. It takes time and practice.

Then I came across the concept of Ladder of Inference, which I realized was something I was striving to do all along, without being aware of its existence. I thought that I should share this wonderful concept.<\/p>\n\n\n\n
Filters?<\/h4>\n\n\n\n
Many of you would be are aware that when you do a google search the results you get are tailored to your profile and search history. You can take a look at this:
https:\/\/www.ted.com\/talks\/eli_pariser_beware_online_filter_bubbles?language=en<\/a> <\/p>\n\n\n\n
Each one of us, has our own world view and view the world through our filters, this can cause issues at times. You may be biased about a person being frivolous and disregard his ideas\/ inputs unknowingly. One way to overcome this is by being self-aware, try be aware of others and practice the ladder of inference technique in your interactions.

Let\u2019s look into the ladder of inference, it says that though the same pool of data and facts are available to all. We are selective about the observations we make. Based on our observations we interpret it where our personal and cultural bias can come in, make assumptions and reach a conclusion. That becomes our belief and then we act according to that. As we act according to our belief, it gets further reinforced.<\/p>\n\n\n\n
$\"\"$ <\/figure>\n\n\n\n
Image courtesy: https:\/\/commons.wikimedia.org\/wiki\/File:Ladder_of_inference.svg<\/a>, https:\/\/creativecommons.org\/licenses\/by-sa\/4.0<\/a> <\/p>\n\n\n\n
Let\u2019s take an example, Mayank, is the Scrum Master and he noticed that Vijay is late for the Retrospective. He happened to be late for the Planning meet too and was unable to complete one of the stories he had picked to work on. Mayank may conclude that Vijay is unprofessional and lacks skills, because he himself is punctual to a fault and will try his best to complete work that he picks up, come what may. In the Retrospective, Mayank may get two differing views on a point being discussed. One from Vijay and another from Mohan a team member who is punctual and usually able to complete the stories he picks up. It is possible that Vijay\u2019s views were more relevant and Mayank ignores them.

The one way for Mayank to work out of this - as a Scrum Master, he looks at all inputs neutrally and when in doubt ascertain facts by asking more open ended questions. For example, he needs to introspect on his assumptions about why Vijay is late in attending sprint events and unable to meet his work commitments. He can probe further and be open to look at additional data which may change his assumptions and conclusions drawn from them.
It\u2019s something that happens to most of us, so being aware of this will help us take more balanced and better decisions consistently.

Some related details:
1. The quote at the start attributed to Viktor Frankl, he is the author of the book Man\u2019s Search for Meaning<\/a>
2. The Ladder of Inference was conceived by organizational psychologist Chris Argyris and used by Peter Senge in The Fifth Discipline: The Art and Practice of the Learning Organization<\/a>
3. Link<\/a> to an article on Separating People from their Ideas and Actions.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n\n\n\n
<\/p>\n","post_title":"Ladder of Inference","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"ladder-of-inference","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:22","post_modified_gmt":"2024-01-29 14:33:22","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15533","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":14052,"post_author":"26","post_date":"2020-04-07 18:43:30","post_date_gmt":"2020-04-07 13:13:30","post_content":"\n
Manoj is a Scrum Master your fellow coach Swamy has coached\nin the past. Swamy has moved on to another organization. You bump into him at\nthe cafeteria and have a short conversation with him. He says he has been\nwanting to talk to you to seek some inputs from you.<\/p>\n\n\n\n
Here is what he has to say:<\/p>\n\n\n\n
During the coaching phase I would discuss challenging\nscenarios with the coach (Swamy) and get insights and different approaches to\nresolve issues. Swamy would share observations which were eye opening and\nbeneficial to me. Swamy would also bring to my attention, if I was crossing the\nboundary with respect to practices or in interaction with team members.
\nNow with no coach associated with the team, I am wondering if there is any way\nI could get these kind of inputs, especially, if I am crossing the boundary in\nany situation.<\/p>\n\n\n\n
He also asks if it is OK to get in touch with you once in a while.\u00a0 As both of you are in a hurry you decide to catch-up later. When you do catch-up with him what suggestions\/inputs\/help will you offer to him? <\/p>\n\n\n\n
Solution:<\/p>\n\n\n\n
In this scenario, I see Manoj\u2019s need is all encompassing starting from specific inputs in the team context to broad canvas where one can look at different approaches and solutions. I have encountered similar questions from many and share a few of the suggestions that I have given at different times and in different context.<\/p>\n\n\n\n
Firstly, I would encourage Manoj to have a trustworthy buddy or a go to person with who he could discuss various issues and solutions. The buddy should be a one who will act as a sounding board and help him explore various options. The buddy could be a peer or it could be a manager. Many times, the role of the buddy will be to just listen, as articulating an issue can bring forth a lot of insight.<\/p>\n\n\n\n
Secondly, I would ask\/check how open he is to receiving feedback and encourage to have a 1-on-1 connect with his team members. This should not be confused with the 1-on-1 that a manager has with his report. This is Manoj as a Scrum Master\/Servant Leader, checking with his team members, in a 1-on-1 setting, at regular cadence on how things are and if anything can be changed. I recommend the cadence of meeting just one team member a week. This meeting will help Manoj start receiving useful inputs after a few such connects. This of course depends on how he makes this connect.<\/p>\n\n\n\n
Lastly, is observing oneself or being self-aware. If he is concerned that something is not going well, would encourage him to a do a quick review\/retrospection of that event or incident. It could be just a personal fist or five. It will stimulate his thinking and impact his approach. Again, this has to be done in measure \u2013 avoid overdoing it.<\/p>\n\n\n\n
Actually, one should be careful in overdoing any of the above. If you do all of the above judiciously, you will have some of the benefits that a coach would bring in, without having a coach.<\/p>\n","post_title":"CHOW #186: Scrum Master Connect","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-186-scrum-master-connect","to_ping":"","pinged":"","post_modified":"2024-01-29 14:33:43","post_modified_gmt":"2024-01-29 14:33:43","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14052","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":14022,"post_author":"26","post_date":"2020-04-06 17:54:07","post_date_gmt":"2020-04-06 12:24:07","post_content":"\n
I had shared my experience with Agile Maturity Assessments <\/a>a while ago, the key challenge over a period of time was <\/p>\n\n\n\n
the lack of enthusiasm due to it being a repeat exercise, no novelty<\/li>
the teams progress towards the maturity slowing down as they achieve maturity, no significant impact. <\/li><\/ul>\n\n\n\n
But a surprise<\/h4>\n\n\n\n
This was my perception, but I was surprised to see a team do the assessment with enthusiasm and rigour and work out the action items with diligence. That too this was a team that had been doing the assessment for a few quarters. Then I saw the same repeated across a few other teams too.

On closer look, what emerged was that the teams had been practicing agile a for a period of time. That had brought in a more in-depth understanding of the values, principles and practices in the team. They were interpreting the same questions with more insight, depth and candour. It was a pleasant surprise and such wonders never cease in the coaching world.

In the past to tide over drop in enthusiasm towards the maturity assessment. I would reiterate the 12th Agile Principle and to focus on continuous improvement would help. <\/p>\n\n\n\n
Health check<\/h4>\n\n\n\n
Words influence one\u2019s thoughts and create a mental picture of what is intended and how it will be achieved. One of the options that came up was terming this exercise a health check <\/strong>instead of maturity assessment. A small change with a great impact, with use of this term the pressure to become mature gets replaced with a desire to stay healthy.<\/p>\n\n\n\n
The idea came from another initiative of my organization<\/a>. One is more open to accept that they may have missed aspects that keep them healthy from the Agile perspective. It also helps the team being alert and open to the fact that there could be a variation in any aspect that could impact the team health. Variation could result in drop in health and that is more palatable than a drop in maturity.

Using this term will help maintain a steady focus on the continuous improvement. <\/p>\n\n\n\n
Bias to action<\/h4>\n\n\n\n
Irrespective of the term used there needs to be a bias towards action. The team needs to identify what they need to get back to healthy, doing a health check and not taking any action to improve is of no consequence.

The environment is important too, the team can make changes that are within their purview and control. Some of the changes identified may need to done at an organizational level. The organization has to help by ensuring there is required support for the same. <\/p>\n\n\n\n
Leadership focus<\/h4>\n\n\n\n
The leaders have good focus on the organization achieving the desired business goals and outcome. To achieve the outcome, the teams have to be healthy and well supported, this part is well understood. The visible and transparent commitment to this is often perceived as lacking or there could a real lacuna. Once this commitment visible to the entire organization it will work wonders.

This requires the leader to focus on the team health related action items, which are often neglected. All the leaders have to do is to look at the team\u2019s action plan, provide the support and check back on how is there progress and provide any help. A cadence of a monthly meet with the team or a set of teams, to look at this is more than sufficient to get this going. <\/p>\n\n\n\n
Changing landscape<\/h4>\n\n\n\n
One of the problems with the maturity\/health check instruments that I used was that the data was not captured. It was more of a survey with anonymous inputs or inputs with consensus. This worked well in the initial stages and provided an overview of where teams were as well as a means to work out improvements.

Attempts were made to consolidate data, the roll up of maturity was not of much use. Consolidating of the improvement items across the organization was a challenge.

With the Agile transformation encompassing the whole organization and number of teams increasing, the need to have the data captured has become important. Now there are tools that do this well as well as organizations are creating their own. Once you capture data it is possible to compare how teams are doing, how organizations are doing with respect to each other. I must stress that this not to see who is doing better, but to share and learn from other teams and organizations. Say a team has challenges with distributed nature of its existence, but another has managed to do well, an opportunity to share and learn exists.

The tools help provide a backlog of the improvement items that are at the team level and the organization level. Though this could be maintained along with the regular backlog, having it separate and close with the inputs from team is useful.

The tools also provide other data, for example one could look at what the team feels vis a vis the stakeholder. We have data for all the teams together too, one has to be careful to ensure that the data is used for improvements and not for rewards.

Lastly, we all stakeholders should ensure that there is action planning and execution.<\/p>\n\n\n\n
Vasu<\/a><\/p>\n","post_title":"More on Agile Maturity \u2013 Health check\u2026","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"more-on-agile-maturity-health-check","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:04","post_modified_gmt":"2024-01-29 14:34:04","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=14022","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13385,"post_author":"26","post_date":"2019-09-23 12:49:35","post_date_gmt":"2019-09-23 07:19:35","post_content":"\n
You are the Scrum Master of the Maven's team and you are happy. You were able to make the Product Owner, Meenakshi understand the necessity to include the technical stories and the technical debt items in the Product Backlog.
The technical story or rather the epic is related to replacing the data base layer with a new one. There is an organization wide move for this change. The technical debt is related to cleaning up the code base, which has become complex over last 18 months. Your new tech lead, Himanshu has impressed upon you and Meenakshi, on the need to do static analysis of the code. He was able to showcase typical gains using a code analyser on a module.

The Release Planning is scheduled for the coming Wednesday and you happen meet Meenakshi at the cafeteria. Meenakshi wants to know how to size the stories that were added recently. She tells that she talked about the additions with her peers. They asked this question and she was unable to answer. What would your answer be as a Scrum Master? <\/p>\n\n\n\n
Solution: <\/strong>The sizing of backlog items helps forecast what will be achieved within the sprint<\/strong> and how many sprints<\/strong> it may take to achieve the release goal.
The latter is approximate, as the number of sprints required is based on the current velocity. The velocity will not be constant, some variation may be there.
My take is that the team must do whatever it takes for them to be able to forecast the above two items and it may vary from team to team. There should be buy-in from the Scrum team i.e., Scrum Master, Development Team, the Product Owner and other stakeholders.
One situation is that the Product Owner is able to understand the details of the technical stories and technical debt. PO is able comprehend its size and prioritize them along with functional stories in the backlog with help from the team. Then you can size the technical stories.

Meenakshi is unable to do so, you will have to arrive at a mechanism to transparently arrive at the sprint forecast as well as the release forecast, that includes the work on technical stories. One option is to set aside some effort every sprint to work on the technical stories, the velocity will reflect only the functional stories and will be less than the usual.
The team should ensure that there is acceptance criteria and done criteria associated with the technical work (or any item in the product backlog) and that is reviewed at the end of the sprint in a transparent manner. <\/p>\n\n\n\n
Would like to know your views.<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n
<\/p>\n","post_title":"CHOW #165 - Should we size technical stories and technical debts?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-165-should-we-size-technical-stories-and-technical-debts","to_ping":"","pinged":"","post_modified":"2024-01-29 14:34:54","post_modified_gmt":"2024-01-29 14:34:54","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13385","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

Page 2 of 6 Previous 1 2 3 … 6 Next

S Vasudev

Chow

CHOW #263 – Should we add a buffer to estimates? When?

by S Vasudev
September 6, 2021

Agile

A story to help with sustaining focus

by S Vasudev
September 6, 2021

Chow

CHOW #245- Swarming in teams

by S Vasudev
May 1, 2021

Agile

Insights from the traditional ways… Agile

by S Vasudev
May 1, 2021

Chow

CHOW #228 – Daily Stand-up over Email

by S Vasudev
January 2, 2021

Agile

Tweaks in the traditional approach… Agile

by S Vasudev
January 1, 2021

Agile

Ladder of Inference

by S Vasudev
August 16, 2020

Chow

CHOW #186: Scrum Master Connect

by S Vasudev
April 7, 2020

Agile

More on Agile Maturity – Health check…

by S Vasudev
April 6, 2020

Chow

CHOW #165 – Should we size technical stories and technical debts?

by S Vasudev
September 23, 2019

Page 2 of 6 Previous 1 2 3 … 6 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:

CHOW #263 – Should we add a buffer to estimates? When?

A story to help with sustaining focus

CHOW #245- Swarming in teams

Insights from the traditional ways… Agile

CHOW #228 – Daily Stand-up over Email

Tweaks in the traditional approach… Agile

Ladder of Inference

CHOW #186: Scrum Master Connect

More on Agile Maturity – Health check…

CHOW #165 – Should we size technical stories and technical debts?

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

Our Offerings

Execution Excellence

Leadership Development

Organizational Excellence

Large-Scale Transformation To Agile

Starting & Scaling Agile Transformation

Fully Automated Analytics Platform

ehancing project management capabilities

Enterprise Wide Digital Transformation

Books

Videos

SPS Podcast

FSL Podcast

Blogs

Challenge Of the Week