More
CALL To Light
To Know
-
Showing the way
Why Agile goes awry and how to fix it
CALL To Light
—
Jul 2019
When Agile software development was born in 2001, it articulated a set of four critical principles to elevate the craft of software development and improve engineering and product manager motivation.
Agile processes go awry, because as companies strive for high performance, they either become too tactical (focusing too much on process and micromanagement) or too adaptive (avoiding long-term goals, timelines, or cross-functional collaboration).
The key is balancing both tactical and adaptive performance. Whether you’re an engineer or product manager, here are a few changes to consider to find this balance, so you can improve your engineering (or any) team’s motivation and performance.
First the team, including executives, should articulate the team’s strategic “challenges.” Challenges take the form of a question, always focused on improving some kind of customer outcome or impact. Think of them as a team’s detailed mission in question-form to trigger expansive thinking. The challenges themselves are developed and iterated by the whole team, including its executive sponsors (and customers). Every single person on the team (or any team for that matter) is asked to contribute ideas to each challenge whenever they want.
Teams often find they waste time by adapting too much. To avoid this, not only should ideas be formed for a strategic challenge, but they should also be executed with fast experiments aimed at learning just enough to know what works for customers. In other words, they should be maximizing their “speed to truth.”
The process of building software (even internal-use software) should be squarely customer-centric.
At the simplest, these principles should hold:
However, even more important is that engineers see with their own eyes how customers use their products. This requires the frontline and the engineers working together to see if the product is creating customer impact.
You want to be clear on how far an engineer should go before they check to see if the direction is still correct. The greater the uncertainty on a team’s hypothesis, and the greater the risk, the shorter that runway should be. With that in mind, the timebox isn’t a deadline. It is a constraint that should guide the level of depth and quality for an experiment before a real test. In this way, timeboxes can increase total motivation.
To make sure you end up with a no-handoff process, the various stakeholders involved should function as a single cross-functional team, also known as a pod. The goal of the pod is to drive collaboration. Each pod should contain the full set of experts needed to deliver a great product. This may include senior executives. In one organization, for example product pods include a product manager, front-end engineer, back-end engineer, designer, a quality engineer, and part-time representation from customer service, and a senior executive from a control function.
Rather than building “Agile” as a religion that cannot be questioned, engineering teams should be in the habit of constantly diagnosing and iterating their own team’s operating model. In the best examples we’ve seen, on a monthly basis, teams diagnose their operating model and decide if it needs changing to produce a better product.
The ability to attract, inspire, and retain digital product talent is becoming mission critical for organizations. Most organizations have fallen prey to a simple message — implement Agile as a series of ceremonies and everything gets better. Unfortunately, this is often not the case when the human-side of the equation is lost. By getting back to the basics of motivation and adaptive performance, you can build an organization that is truly agile.
Read the full article, here.
When Agile software development was born in 2001, it articulated a set of four critical principles to elevate the craft of software development and improve engineering and product manager motivation.
Agile processes go awry, because as companies strive for high performance, they either become too tactical (focusing too much on process and micromanagement) or too adaptive (avoiding long-term goals, timelines, or cross-functional collaboration).
The key is balancing both tactical and adaptive performance. Whether you’re an engineer or product manager, here are a few changes to consider to find this balance, so you can improve your engineering (or any) team’s motivation and performance.
First the team, including executives, should articulate the team’s strategic “challenges.” Challenges take the form of a question, always focused on improving some kind of customer outcome or impact. Think of them as a team’s detailed mission in question-form to trigger expansive thinking. The challenges themselves are developed and iterated by the whole team, including its executive sponsors (and customers). Every single person on the team (or any team for that matter) is asked to contribute ideas to each challenge whenever they want.
Teams often find they waste time by adapting too much. To avoid this, not only should ideas be formed for a strategic challenge, but they should also be executed with fast experiments aimed at learning just enough to know what works for customers. In other words, they should be maximizing their “speed to truth.”
The process of building software (even internal-use software) should be squarely customer-centric.
At the simplest, these principles should hold:
However, even more important is that engineers see with their own eyes how customers use their products. This requires the frontline and the engineers working together to see if the product is creating customer impact.
You want to be clear on how far an engineer should go before they check to see if the direction is still correct. The greater the uncertainty on a team’s hypothesis, and the greater the risk, the shorter that runway should be. With that in mind, the timebox isn’t a deadline. It is a constraint that should guide the level of depth and quality for an experiment before a real test. In this way, timeboxes can increase total motivation.
To make sure you end up with a no-handoff process, the various stakeholders involved should function as a single cross-functional team, also known as a pod. The goal of the pod is to drive collaboration. Each pod should contain the full set of experts needed to deliver a great product. This may include senior executives. In one organization, for example product pods include a product manager, front-end engineer, back-end engineer, designer, a quality engineer, and part-time representation from customer service, and a senior executive from a control function.
Rather than building “Agile” as a religion that cannot be questioned, engineering teams should be in the habit of constantly diagnosing and iterating their own team’s operating model. In the best examples we’ve seen, on a monthly basis, teams diagnose their operating model and decide if it needs changing to produce a better product.
The ability to attract, inspire, and retain digital product talent is becoming mission critical for organizations. Most organizations have fallen prey to a simple message — implement Agile as a series of ceremonies and everything gets better. Unfortunately, this is often not the case when the human-side of the equation is lost. By getting back to the basics of motivation and adaptive performance, you can build an organization that is truly agile.
Read the full article, here.
When Agile software development was born in 2001, it articulated a set of four critical principles to elevate the craft of software development and improve engineering and product manager motivation.
Agile processes go awry, because as companies strive for high performance, they either become too tactical (focusing too much on process and micromanagement) or too adaptive (avoiding long-term goals, timelines, or cross-functional collaboration).
The key is balancing both tactical and adaptive performance. Whether you’re an engineer or product manager, here are a few changes to consider to find this balance, so you can improve your engineering (or any) team’s motivation and performance.
First the team, including executives, should articulate the team’s strategic “challenges.” Challenges take the form of a question, always focused on improving some kind of customer outcome or impact. Think of them as a team’s detailed mission in question-form to trigger expansive thinking. The challenges themselves are developed and iterated by the whole team, including its executive sponsors (and customers). Every single person on the team (or any team for that matter) is asked to contribute ideas to each challenge whenever they want.
Teams often find they waste time by adapting too much. To avoid this, not only should ideas be formed for a strategic challenge, but they should also be executed with fast experiments aimed at learning just enough to know what works for customers. In other words, they should be maximizing their “speed to truth.”
The process of building software (even internal-use software) should be squarely customer-centric.
At the simplest, these principles should hold:
However, even more important is that engineers see with their own eyes how customers use their products. This requires the frontline and the engineers working together to see if the product is creating customer impact.
You want to be clear on how far an engineer should go before they check to see if the direction is still correct. The greater the uncertainty on a team’s hypothesis, and the greater the risk, the shorter that runway should be. With that in mind, the timebox isn’t a deadline. It is a constraint that should guide the level of depth and quality for an experiment before a real test. In this way, timeboxes can increase total motivation.
To make sure you end up with a no-handoff process, the various stakeholders involved should function as a single cross-functional team, also known as a pod. The goal of the pod is to drive collaboration. Each pod should contain the full set of experts needed to deliver a great product. This may include senior executives. In one organization, for example product pods include a product manager, front-end engineer, back-end engineer, designer, a quality engineer, and part-time representation from customer service, and a senior executive from a control function.
Rather than building “Agile” as a religion that cannot be questioned, engineering teams should be in the habit of constantly diagnosing and iterating their own team’s operating model. In the best examples we’ve seen, on a monthly basis, teams diagnose their operating model and decide if it needs changing to produce a better product.
The ability to attract, inspire, and retain digital product talent is becoming mission critical for organizations. Most organizations have fallen prey to a simple message — implement Agile as a series of ceremonies and everything gets better. Unfortunately, this is often not the case when the human-side of the equation is lost. By getting back to the basics of motivation and adaptive performance, you can build an organization that is truly agile.
Read the full article, here.
.png)
