People tell me I have “drunk the Kool-Aid.” Maybe that’s true.
I’ve dedicated the last 18 years of my professional life to working in commercial software product development environments—from employee to executive. As the current Managing Partner of an advisory services firm, I have seen just about all there is to see in business, working with startups whose employees range from three to large organizations that have tens of thousands. Nowadays , I spend most of my time helping organizations with product delivery issues improve, scale or prepare for IPO.
I have learned that regardless of industry, organization size, or belief in an organization’s individuality, most of these environments actually have a lot in common—including teams comprised of good people with good intentions. Unfortunately, most of these teams are lacking a common framework in which to operate.
I believe that an Agile framework is much better than how we used to get work done. I have found that the application of Lean Agile principles with consistency, just like a good exercise regime, can transform how product is delivered to market.
Extensive writing already exists defining Lean Agile principles and my intent is not to re-write these articles. The Scaled Agile Framework (SAFe ©) website and texts are an excellent resource on this topic. While all of the Lean Agile principles have value and importance, I have found organizations are most likely to get in shape and stay there, by staying mindful of the following.
Yes, yes, I know—I have heard all of the objections to this. “I already received training (at this company or someplace else),” “I already know what Agile is all about,” and so on. It’s true: most teams today have had exposure to Agile in some form. Many have lost their belief that it’s effective.
While it may cost more up front, a team reset with re-training is sometimes the only way to get things back on track. Re-training teams together enables one or more teams to implement the same Agile framework within the current organizational context. They can share a revised set of principles, roles, responsibilities, and processes. This enables teams to collaborate much more effectively and deliver value to market faster than before.
During my first week at a new organization I was told, “You may have to get a whole new team. The team you are working with is terrible.” I am proud to say that several years later, many of the same people still worked at that organization in similar or different roles. I really do believe people are doing their best (with occasional exceptions). What’s really going on is that teams are struggling to connect their work to the business objectives and team members are often not assigned to roles that play to their strengths.
Managers who take the time to optimize people to roles will reap the benefits for years to come (and form valuable, long-term relationships in the process). Most people are not incompetent or lazy. On the contrary, they just need to know what to do and why they are doing it, and have the skills and information required to get the work done.
There must be partnership from the top-down between product and tech: if one tips the canoe, they all fall in. Unfortunately, it is not uncommon to find trust issues between product and technology. This is the most important issue to resolve. Like most relationship issues, these take time to develop and will take time to go away. Often I hear things like:
This destructive talk needs to stop immediately. Product has the responsibility to determine business value and priority while engineering has the responsibility of building quality, scalable, and releasable code. One needs the other and they sink or swim together. This needs to be the message from the top-down, left, and right. It is the responsibility of leadership to carry and reinforce this message. To do anything different is sabotage.
This seems simple, but in almost every engagement I start, clear and current business objectives and priorities are missing. Frequently, teams do not understand what is most important to the organization. Every team member at every level of the organization should have access to and understand the organization’s strategic objectives. Furthermore, they need to understand how their work ties to those objectives.
Remember good old requirements traceability–today’s Lean Agile practices show us “strategic traceability” is far more valuable. When we start working with new teams, we often ask “What are the current strategic objectives?”, “How does this feature or user story support specific strategic objectives?” Most of the time we find that the teams can’t articulate the strategic objectives nor connect them to their work, When they do, amazing things happen; we have seen teams come up with solutions not imagined up front or when they are at an impasse on how to best achieve value, the traceability to strategy can be the tie breaker.
Tying features to business value will empower teams to prioritize more effectively, enabling them to develop and release product that will make the greatest impact to the organization. Working on what matters is exciting and when people feel engaged with what’s important, amazing things happen. Leadership, it is your job to provide clear business objectives to your teams so they can make these priority connections.
Yes, you have probably reorganized every 18 months trying to solve delivery issues, but you may have to do this again. Reorganizing teams to minimize cross-team dependencies and grouping teams to deliver large initiatives will decrease planning frustration and increase the ability to manage risk and change. Reorganize before team training if possible and be open to doing it again once teams have learned from this new way of working.
There, I said it. I know this flies in the face of what we have been taught to create: flat, self-organizing teams. I do not want to take away from the importance of each team member feeling responsible and empowered. However, a tech lead role can provide a lot of value to the team, especially in troubled organizations rebooting their Agile framework. It’s the third leg to the stool, giving the team the balance to stand (product owner, scrum master, tech lead). I have seen the tech lead work effectively to clear engineering impediments within the team and serve as the technical point of contact for the team during the early days of an agile transformation or reboot. As the use of Agile matures in your organization, the need for this separate role may diminish.
Aakk—more Agile heresy! Sometimes there are dependencies that fall outside of teams using an Agile framework. There are key initiatives that span many teams that need to be coordinated. While I would love to have an entire organization utilizing an Agile framework, that’s just not happening in many organizations.
Whenever I hire a scrum master, I make sure I evaluate whether s/he is comfortable wearing a project coordinator/manager hat if needed. Why make an unwilling tech or product person coordinate when there are individuals who like to coordinate? A project management or a lead scrum master role can be extremely effective, and the attitude that these should not be utilized drives me a little bananas.
Really, the goal is to deliver valuable products to market. How can that happen if the person responsible for the product does not spend time with his or her team? Too often I have encountered product owners or managers who are unavailable to the team or worse, uninterested in the work of the team.
A product owner is a critical team role and the team’s PO is responsible for what the team delivers. The product owner should want to be part of this. In scrum, this means attending daily stand-ups and other scrum meetings, writing and collaborating with the team on epics and stories refinement, assigning business value, and being available to help with prioritization as is needed by the team.
Don’t assume that a disparate set of scrum masters has the authority to provide the Agile framework with the care and feeding it needs to stay alive and effective. It’s the support of the framework that is most important to preserve its effectiveness. Leaving this responsibility to centers of excellence is not enough support. This needs to be the job of one or many people.
While the term “PMO” has lost is shine in many circles, my experience has been that a PMO (or similar organization) to own the framework is quite effective. PMOs that only have responsibility for process can be perceived as unhelpful and ineffective. However, PMOs that share responsibility for delivery with engineering and product by serving as the dotted or straight line reporting structure for the scrum masters, can provide even greater value to the organization, as they really are part of the team.
We humans do not see much benefit in our health when we head to gym for a month and then leave our sneakers in the closet for the other 11 months of the year. Staying in good physical shape requires an individual lifestyle change.
Getting an organization into shape with Lean Agile is much the same. It requires that leadership and teams set an intention and follow through. Not just for a month, a quarter or even a half-year, but for the life of the business. There must be an organizational lifestyle change. Clear priorities from leadership, a sense of ownership and well understood Lean Agile roles and responsibilities are what it takes to get an Agile framework in shape and keep it that way.
People tell me I have “drunk the Kool-Aid.” Maybe that’s true.
I’ve dedicated the last 18 years of my professional life to working in commercial software product development environments—from employee to executive. As the current Managing Partner of an advisory services firm, I have seen just about all there is to see in business, working with startups whose employees range from three to large organizations that have tens of thousands. Nowadays , I spend most of my time helping organizations with product delivery issues improve, scale or prepare for IPO.
I have learned that regardless of industry, organization size, or belief in an organization’s individuality, most of these environments actually have a lot in common—including teams comprised of good people with good intentions. Unfortunately, most of these teams are lacking a common framework in which to operate.
I believe that an Agile framework is much better than how we used to get work done. I have found that the application of Lean Agile principles with consistency, just like a good exercise regime, can transform how product is delivered to market.
Extensive writing already exists defining Lean Agile principles and my intent is not to re-write these articles. The Scaled Agile Framework (SAFe ©) website and texts are an excellent resource on this topic. While all of the Lean Agile principles have value and importance, I have found organizations are most likely to get in shape and stay there, by staying mindful of the following.
Yes, yes, I know—I have heard all of the objections to this. “I already received training (at this company or someplace else),” “I already know what Agile is all about,” and so on. It’s true: most teams today have had exposure to Agile in some form. Many have lost their belief that it’s effective.
While it may cost more up front, a team reset with re-training is sometimes the only way to get things back on track. Re-training teams together enables one or more teams to implement the same Agile framework within the current organizational context. They can share a revised set of principles, roles, responsibilities, and processes. This enables teams to collaborate much more effectively and deliver value to market faster than before.
During my first week at a new organization I was told, “You may have to get a whole new team. The team you are working with is terrible.” I am proud to say that several years later, many of the same people still worked at that organization in similar or different roles. I really do believe people are doing their best (with occasional exceptions). What’s really going on is that teams are struggling to connect their work to the business objectives and team members are often not assigned to roles that play to their strengths.
Managers who take the time to optimize people to roles will reap the benefits for years to come (and form valuable, long-term relationships in the process). Most people are not incompetent or lazy. On the contrary, they just need to know what to do and why they are doing it, and have the skills and information required to get the work done.
There must be partnership from the top-down between product and tech: if one tips the canoe, they all fall in. Unfortunately, it is not uncommon to find trust issues between product and technology. This is the most important issue to resolve. Like most relationship issues, these take time to develop and will take time to go away. Often I hear things like:
This destructive talk needs to stop immediately. Product has the responsibility to determine business value and priority while engineering has the responsibility of building quality, scalable, and releasable code. One needs the other and they sink or swim together. This needs to be the message from the top-down, left, and right. It is the responsibility of leadership to carry and reinforce this message. To do anything different is sabotage.
This seems simple, but in almost every engagement I start, clear and current business objectives and priorities are missing. Frequently, teams do not understand what is most important to the organization. Every team member at every level of the organization should have access to and understand the organization’s strategic objectives. Furthermore, they need to understand how their work ties to those objectives.
Remember good old requirements traceability–today’s Lean Agile practices show us “strategic traceability” is far more valuable. When we start working with new teams, we often ask “What are the current strategic objectives?”, “How does this feature or user story support specific strategic objectives?” Most of the time we find that the teams can’t articulate the strategic objectives nor connect them to their work, When they do, amazing things happen; we have seen teams come up with solutions not imagined up front or when they are at an impasse on how to best achieve value, the traceability to strategy can be the tie breaker.
Tying features to business value will empower teams to prioritize more effectively, enabling them to develop and release product that will make the greatest impact to the organization. Working on what matters is exciting and when people feel engaged with what’s important, amazing things happen. Leadership, it is your job to provide clear business objectives to your teams so they can make these priority connections.
Yes, you have probably reorganized every 18 months trying to solve delivery issues, but you may have to do this again. Reorganizing teams to minimize cross-team dependencies and grouping teams to deliver large initiatives will decrease planning frustration and increase the ability to manage risk and change. Reorganize before team training if possible and be open to doing it again once teams have learned from this new way of working.
There, I said it. I know this flies in the face of what we have been taught to create: flat, self-organizing teams. I do not want to take away from the importance of each team member feeling responsible and empowered. However, a tech lead role can provide a lot of value to the team, especially in troubled organizations rebooting their Agile framework. It’s the third leg to the stool, giving the team the balance to stand (product owner, scrum master, tech lead). I have seen the tech lead work effectively to clear engineering impediments within the team and serve as the technical point of contact for the team during the early days of an agile transformation or reboot. As the use of Agile matures in your organization, the need for this separate role may diminish.
Aakk—more Agile heresy! Sometimes there are dependencies that fall outside of teams using an Agile framework. There are key initiatives that span many teams that need to be coordinated. While I would love to have an entire organization utilizing an Agile framework, that’s just not happening in many organizations.
Whenever I hire a scrum master, I make sure I evaluate whether s/he is comfortable wearing a project coordinator/manager hat if needed. Why make an unwilling tech or product person coordinate when there are individuals who like to coordinate? A project management or a lead scrum master role can be extremely effective, and the attitude that these should not be utilized drives me a little bananas.
Really, the goal is to deliver valuable products to market. How can that happen if the person responsible for the product does not spend time with his or her team? Too often I have encountered product owners or managers who are unavailable to the team or worse, uninterested in the work of the team.
A product owner is a critical team role and the team’s PO is responsible for what the team delivers. The product owner should want to be part of this. In scrum, this means attending daily stand-ups and other scrum meetings, writing and collaborating with the team on epics and stories refinement, assigning business value, and being available to help with prioritization as is needed by the team.
Don’t assume that a disparate set of scrum masters has the authority to provide the Agile framework with the care and feeding it needs to stay alive and effective. It’s the support of the framework that is most important to preserve its effectiveness. Leaving this responsibility to centers of excellence is not enough support. This needs to be the job of one or many people.
While the term “PMO” has lost is shine in many circles, my experience has been that a PMO (or similar organization) to own the framework is quite effective. PMOs that only have responsibility for process can be perceived as unhelpful and ineffective. However, PMOs that share responsibility for delivery with engineering and product by serving as the dotted or straight line reporting structure for the scrum masters, can provide even greater value to the organization, as they really are part of the team.
We humans do not see much benefit in our health when we head to gym for a month and then leave our sneakers in the closet for the other 11 months of the year. Staying in good physical shape requires an individual lifestyle change.
Getting an organization into shape with Lean Agile is much the same. It requires that leadership and teams set an intention and follow through. Not just for a month, a quarter or even a half-year, but for the life of the business. There must be an organizational lifestyle change. Clear priorities from leadership, a sense of ownership and well understood Lean Agile roles and responsibilities are what it takes to get an Agile framework in shape and keep it that way.
People tell me I have “drunk the Kool-Aid.” Maybe that’s true.
I’ve dedicated the last 18 years of my professional life to working in commercial software product development environments—from employee to executive. As the current Managing Partner of an advisory services firm, I have seen just about all there is to see in business, working with startups whose employees range from three to large organizations that have tens of thousands. Nowadays , I spend most of my time helping organizations with product delivery issues improve, scale or prepare for IPO.
I have learned that regardless of industry, organization size, or belief in an organization’s individuality, most of these environments actually have a lot in common—including teams comprised of good people with good intentions. Unfortunately, most of these teams are lacking a common framework in which to operate.
I believe that an Agile framework is much better than how we used to get work done. I have found that the application of Lean Agile principles with consistency, just like a good exercise regime, can transform how product is delivered to market.
Extensive writing already exists defining Lean Agile principles and my intent is not to re-write these articles. The Scaled Agile Framework (SAFe ©) website and texts are an excellent resource on this topic. While all of the Lean Agile principles have value and importance, I have found organizations are most likely to get in shape and stay there, by staying mindful of the following.
Yes, yes, I know—I have heard all of the objections to this. “I already received training (at this company or someplace else),” “I already know what Agile is all about,” and so on. It’s true: most teams today have had exposure to Agile in some form. Many have lost their belief that it’s effective.
While it may cost more up front, a team reset with re-training is sometimes the only way to get things back on track. Re-training teams together enables one or more teams to implement the same Agile framework within the current organizational context. They can share a revised set of principles, roles, responsibilities, and processes. This enables teams to collaborate much more effectively and deliver value to market faster than before.
During my first week at a new organization I was told, “You may have to get a whole new team. The team you are working with is terrible.” I am proud to say that several years later, many of the same people still worked at that organization in similar or different roles. I really do believe people are doing their best (with occasional exceptions). What’s really going on is that teams are struggling to connect their work to the business objectives and team members are often not assigned to roles that play to their strengths.
Managers who take the time to optimize people to roles will reap the benefits for years to come (and form valuable, long-term relationships in the process). Most people are not incompetent or lazy. On the contrary, they just need to know what to do and why they are doing it, and have the skills and information required to get the work done.
There must be partnership from the top-down between product and tech: if one tips the canoe, they all fall in. Unfortunately, it is not uncommon to find trust issues between product and technology. This is the most important issue to resolve. Like most relationship issues, these take time to develop and will take time to go away. Often I hear things like:
This destructive talk needs to stop immediately. Product has the responsibility to determine business value and priority while engineering has the responsibility of building quality, scalable, and releasable code. One needs the other and they sink or swim together. This needs to be the message from the top-down, left, and right. It is the responsibility of leadership to carry and reinforce this message. To do anything different is sabotage.
This seems simple, but in almost every engagement I start, clear and current business objectives and priorities are missing. Frequently, teams do not understand what is most important to the organization. Every team member at every level of the organization should have access to and understand the organization’s strategic objectives. Furthermore, they need to understand how their work ties to those objectives.
Remember good old requirements traceability–today’s Lean Agile practices show us “strategic traceability” is far more valuable. When we start working with new teams, we often ask “What are the current strategic objectives?”, “How does this feature or user story support specific strategic objectives?” Most of the time we find that the teams can’t articulate the strategic objectives nor connect them to their work, When they do, amazing things happen; we have seen teams come up with solutions not imagined up front or when they are at an impasse on how to best achieve value, the traceability to strategy can be the tie breaker.
Tying features to business value will empower teams to prioritize more effectively, enabling them to develop and release product that will make the greatest impact to the organization. Working on what matters is exciting and when people feel engaged with what’s important, amazing things happen. Leadership, it is your job to provide clear business objectives to your teams so they can make these priority connections.
Yes, you have probably reorganized every 18 months trying to solve delivery issues, but you may have to do this again. Reorganizing teams to minimize cross-team dependencies and grouping teams to deliver large initiatives will decrease planning frustration and increase the ability to manage risk and change. Reorganize before team training if possible and be open to doing it again once teams have learned from this new way of working.
There, I said it. I know this flies in the face of what we have been taught to create: flat, self-organizing teams. I do not want to take away from the importance of each team member feeling responsible and empowered. However, a tech lead role can provide a lot of value to the team, especially in troubled organizations rebooting their Agile framework. It’s the third leg to the stool, giving the team the balance to stand (product owner, scrum master, tech lead). I have seen the tech lead work effectively to clear engineering impediments within the team and serve as the technical point of contact for the team during the early days of an agile transformation or reboot. As the use of Agile matures in your organization, the need for this separate role may diminish.
Aakk—more Agile heresy! Sometimes there are dependencies that fall outside of teams using an Agile framework. There are key initiatives that span many teams that need to be coordinated. While I would love to have an entire organization utilizing an Agile framework, that’s just not happening in many organizations.
Whenever I hire a scrum master, I make sure I evaluate whether s/he is comfortable wearing a project coordinator/manager hat if needed. Why make an unwilling tech or product person coordinate when there are individuals who like to coordinate? A project management or a lead scrum master role can be extremely effective, and the attitude that these should not be utilized drives me a little bananas.
Really, the goal is to deliver valuable products to market. How can that happen if the person responsible for the product does not spend time with his or her team? Too often I have encountered product owners or managers who are unavailable to the team or worse, uninterested in the work of the team.
A product owner is a critical team role and the team’s PO is responsible for what the team delivers. The product owner should want to be part of this. In scrum, this means attending daily stand-ups and other scrum meetings, writing and collaborating with the team on epics and stories refinement, assigning business value, and being available to help with prioritization as is needed by the team.
Don’t assume that a disparate set of scrum masters has the authority to provide the Agile framework with the care and feeding it needs to stay alive and effective. It’s the support of the framework that is most important to preserve its effectiveness. Leaving this responsibility to centers of excellence is not enough support. This needs to be the job of one or many people.
While the term “PMO” has lost is shine in many circles, my experience has been that a PMO (or similar organization) to own the framework is quite effective. PMOs that only have responsibility for process can be perceived as unhelpful and ineffective. However, PMOs that share responsibility for delivery with engineering and product by serving as the dotted or straight line reporting structure for the scrum masters, can provide even greater value to the organization, as they really are part of the team.
We humans do not see much benefit in our health when we head to gym for a month and then leave our sneakers in the closet for the other 11 months of the year. Staying in good physical shape requires an individual lifestyle change.
Getting an organization into shape with Lean Agile is much the same. It requires that leadership and teams set an intention and follow through. Not just for a month, a quarter or even a half-year, but for the life of the business. There must be an organizational lifestyle change. Clear priorities from leadership, a sense of ownership and well understood Lean Agile roles and responsibilities are what it takes to get an Agile framework in shape and keep it that way.
People tell me I have “drunk the Kool-Aid.” Maybe that’s true.
I’ve dedicated the last 18 years of my professional life to working in commercial software product development environments—from employee to executive. As the current Managing Partner of an advisory services firm, I have seen just about all there is to see in business, working with startups whose employees range from three to large organizations that have tens of thousands. Nowadays , I spend most of my time helping organizations with product delivery issues improve, scale or prepare for IPO.
I have learned that regardless of industry, organization size, or belief in an organization’s individuality, most of these environments actually have a lot in common—including teams comprised of good people with good intentions. Unfortunately, most of these teams are lacking a common framework in which to operate.
I believe that an Agile framework is much better than how we used to get work done. I have found that the application of Lean Agile principles with consistency, just like a good exercise regime, can transform how product is delivered to market.
Extensive writing already exists defining Lean Agile principles and my intent is not to re-write these articles. The Scaled Agile Framework (SAFe ©) website and texts are an excellent resource on this topic. While all of the Lean Agile principles have value and importance, I have found organizations are most likely to get in shape and stay there, by staying mindful of the following.
Yes, yes, I know—I have heard all of the objections to this. “I already received training (at this company or someplace else),” “I already know what Agile is all about,” and so on. It’s true: most teams today have had exposure to Agile in some form. Many have lost their belief that it’s effective.
While it may cost more up front, a team reset with re-training is sometimes the only way to get things back on track. Re-training teams together enables one or more teams to implement the same Agile framework within the current organizational context. They can share a revised set of principles, roles, responsibilities, and processes. This enables teams to collaborate much more effectively and deliver value to market faster than before.
During my first week at a new organization I was told, “You may have to get a whole new team. The team you are working with is terrible.” I am proud to say that several years later, many of the same people still worked at that organization in similar or different roles. I really do believe people are doing their best (with occasional exceptions). What’s really going on is that teams are struggling to connect their work to the business objectives and team members are often not assigned to roles that play to their strengths.
Managers who take the time to optimize people to roles will reap the benefits for years to come (and form valuable, long-term relationships in the process). Most people are not incompetent or lazy. On the contrary, they just need to know what to do and why they are doing it, and have the skills and information required to get the work done.
There must be partnership from the top-down between product and tech: if one tips the canoe, they all fall in. Unfortunately, it is not uncommon to find trust issues between product and technology. This is the most important issue to resolve. Like most relationship issues, these take time to develop and will take time to go away. Often I hear things like:
This destructive talk needs to stop immediately. Product has the responsibility to determine business value and priority while engineering has the responsibility of building quality, scalable, and releasable code. One needs the other and they sink or swim together. This needs to be the message from the top-down, left, and right. It is the responsibility of leadership to carry and reinforce this message. To do anything different is sabotage.
This seems simple, but in almost every engagement I start, clear and current business objectives and priorities are missing. Frequently, teams do not understand what is most important to the organization. Every team member at every level of the organization should have access to and understand the organization’s strategic objectives. Furthermore, they need to understand how their work ties to those objectives.
Remember good old requirements traceability–today’s Lean Agile practices show us “strategic traceability” is far more valuable. When we start working with new teams, we often ask “What are the current strategic objectives?”, “How does this feature or user story support specific strategic objectives?” Most of the time we find that the teams can’t articulate the strategic objectives nor connect them to their work, When they do, amazing things happen; we have seen teams come up with solutions not imagined up front or when they are at an impasse on how to best achieve value, the traceability to strategy can be the tie breaker.
Tying features to business value will empower teams to prioritize more effectively, enabling them to develop and release product that will make the greatest impact to the organization. Working on what matters is exciting and when people feel engaged with what’s important, amazing things happen. Leadership, it is your job to provide clear business objectives to your teams so they can make these priority connections.
Yes, you have probably reorganized every 18 months trying to solve delivery issues, but you may have to do this again. Reorganizing teams to minimize cross-team dependencies and grouping teams to deliver large initiatives will decrease planning frustration and increase the ability to manage risk and change. Reorganize before team training if possible and be open to doing it again once teams have learned from this new way of working.
There, I said it. I know this flies in the face of what we have been taught to create: flat, self-organizing teams. I do not want to take away from the importance of each team member feeling responsible and empowered. However, a tech lead role can provide a lot of value to the team, especially in troubled organizations rebooting their Agile framework. It’s the third leg to the stool, giving the team the balance to stand (product owner, scrum master, tech lead). I have seen the tech lead work effectively to clear engineering impediments within the team and serve as the technical point of contact for the team during the early days of an agile transformation or reboot. As the use of Agile matures in your organization, the need for this separate role may diminish.
Aakk—more Agile heresy! Sometimes there are dependencies that fall outside of teams using an Agile framework. There are key initiatives that span many teams that need to be coordinated. While I would love to have an entire organization utilizing an Agile framework, that’s just not happening in many organizations.
Whenever I hire a scrum master, I make sure I evaluate whether s/he is comfortable wearing a project coordinator/manager hat if needed. Why make an unwilling tech or product person coordinate when there are individuals who like to coordinate? A project management or a lead scrum master role can be extremely effective, and the attitude that these should not be utilized drives me a little bananas.
Really, the goal is to deliver valuable products to market. How can that happen if the person responsible for the product does not spend time with his or her team? Too often I have encountered product owners or managers who are unavailable to the team or worse, uninterested in the work of the team.
A product owner is a critical team role and the team’s PO is responsible for what the team delivers. The product owner should want to be part of this. In scrum, this means attending daily stand-ups and other scrum meetings, writing and collaborating with the team on epics and stories refinement, assigning business value, and being available to help with prioritization as is needed by the team.
Don’t assume that a disparate set of scrum masters has the authority to provide the Agile framework with the care and feeding it needs to stay alive and effective. It’s the support of the framework that is most important to preserve its effectiveness. Leaving this responsibility to centers of excellence is not enough support. This needs to be the job of one or many people.
While the term “PMO” has lost is shine in many circles, my experience has been that a PMO (or similar organization) to own the framework is quite effective. PMOs that only have responsibility for process can be perceived as unhelpful and ineffective. However, PMOs that share responsibility for delivery with engineering and product by serving as the dotted or straight line reporting structure for the scrum masters, can provide even greater value to the organization, as they really are part of the team.
We humans do not see much benefit in our health when we head to gym for a month and then leave our sneakers in the closet for the other 11 months of the year. Staying in good physical shape requires an individual lifestyle change.
Getting an organization into shape with Lean Agile is much the same. It requires that leadership and teams set an intention and follow through. Not just for a month, a quarter or even a half-year, but for the life of the business. There must be an organizational lifestyle change. Clear priorities from leadership, a sense of ownership and well understood Lean Agile roles and responsibilities are what it takes to get an Agile framework in shape and keep it that way.
.png)
