My journey in Agile began in 2006 when I was an employee leading a traditional PMO and production support team. Our team had already revised a lot of our development processes to follow a clear “waterfall” process with stage gates and sign-offs. We had also spent a lot of time defining and supporting roles and responsibilities, making clear each team’s priority. Our efforts resulted in an increase in productivity, trust, and predictability.
Then we hit a wall.
I embarked on a campaign to leverage a framework I had read about for a few years called Agile (specifically Scrum). It took about three months to receive buy-in and support. We started on an Agile transformation that ultimately trained 12 teams over the course of one year. Even by my measures today — and feedback from others who look back on that time — it was an impressive transformation.
Now, as a consultant and business owner who guides companies through their Agile and Scaled Agile transformations, I think back to that time. I think about what primary ingredients that first transformation had that made it feel so different from what I see in many organizations today.
Agile was new for everyone. No one, that I was aware of, had received past Agile training. We were learning something new together.
We had leadership support. Yes, it took work to garner the support, but we did not begin the process of training and transformation until the head of engineering, product, and even the president of the company were on board with our efforts. We then moved on to get support from the engineering and product managers before training teams. Support didn’t stop with funding training: it continued through monitoring and managing the metrics, alignment of employee goals, and ongoing support of the teams.
We generated excitement and participation. Our first group to “go Agile” was a group of three teams building a brand new product. This group was having trouble getting off the ground. Their testimonial and early success after training inspired others to volunteer.
Most organizations will have already received some level of Agile training. Unfortunately, it does not usually happen among the same team members or even within the same organization. Another problem lies in not seeing or learning from many ineffective uses of the Agile framework.
This is not a new issue. Leadership often struggles to support teams or simply isn’t interested in providing the necessary guidance. The use of Agile has gone stale. Organizations are “sort-of Agile,” but there is a gap between where they are and where they are meant to be.
This, of course, is where the solution lies.
My experience is that an organization of 100-300 tech and product people will take at least 12-18 months to work through an Agile reboot or scaled Agile implementation. Larger organizations may take even longer. Luckily, short-term alignment and progress don’t have to wait. Here are 7 tips I recommend to organizations:
It is important in any organization for teams to understand and share the same priorities. Additionally, you want to make sure that the work is clearly defined using acceptance criteria and that scope will deliver some increment of value to the marketplace.
Implement early definitions of the roles and responsibilities for product and technical leadership. Deliver the message that they are in this canoe together and thus must work together to execute against the top priorities.
Make small obvious changes to execute against the top priorities, even if it means that just a few people or teams are altered. This may need to change again after Agile training, but since we want to promote focus on the priorities, this is the right place to start.
Again, this should be done with the top priorities in mind. Assigning and define a product and technical lead role for these key initiatives. Also look at assigning and defining roles like the Scrum master or program manager, test or automation lead, release management/DevOps, and other key roles needed to deliver different features to the marketplace.
Create and communicate training plans for leadership as well as the teams that align with the team re-boot or Scaled Agile transformation
Develop a process for providing transparency about progress around the key priorities. Some examples include:
Finally, celebrate your wins early and often. This promotes value delivery and is another way to make progress clear to teams. Just realize that if you mind the gap, your organization will have a lot to celebrate!
My journey in Agile began in 2006 when I was an employee leading a traditional PMO and production support team. Our team had already revised a lot of our development processes to follow a clear “waterfall” process with stage gates and sign-offs. We had also spent a lot of time defining and supporting roles and responsibilities, making clear each team’s priority. Our efforts resulted in an increase in productivity, trust, and predictability.
Then we hit a wall.
I embarked on a campaign to leverage a framework I had read about for a few years called Agile (specifically Scrum). It took about three months to receive buy-in and support. We started on an Agile transformation that ultimately trained 12 teams over the course of one year. Even by my measures today — and feedback from others who look back on that time — it was an impressive transformation.
Now, as a consultant and business owner who guides companies through their Agile and Scaled Agile transformations, I think back to that time. I think about what primary ingredients that first transformation had that made it feel so different from what I see in many organizations today.
Agile was new for everyone. No one, that I was aware of, had received past Agile training. We were learning something new together.
We had leadership support. Yes, it took work to garner the support, but we did not begin the process of training and transformation until the head of engineering, product, and even the president of the company were on board with our efforts. We then moved on to get support from the engineering and product managers before training teams. Support didn’t stop with funding training: it continued through monitoring and managing the metrics, alignment of employee goals, and ongoing support of the teams.
We generated excitement and participation. Our first group to “go Agile” was a group of three teams building a brand new product. This group was having trouble getting off the ground. Their testimonial and early success after training inspired others to volunteer.
Most organizations will have already received some level of Agile training. Unfortunately, it does not usually happen among the same team members or even within the same organization. Another problem lies in not seeing or learning from many ineffective uses of the Agile framework.
This is not a new issue. Leadership often struggles to support teams or simply isn’t interested in providing the necessary guidance. The use of Agile has gone stale. Organizations are “sort-of Agile,” but there is a gap between where they are and where they are meant to be.
This, of course, is where the solution lies.
My experience is that an organization of 100-300 tech and product people will take at least 12-18 months to work through an Agile reboot or scaled Agile implementation. Larger organizations may take even longer. Luckily, short-term alignment and progress don’t have to wait. Here are 7 tips I recommend to organizations:
It is important in any organization for teams to understand and share the same priorities. Additionally, you want to make sure that the work is clearly defined using acceptance criteria and that scope will deliver some increment of value to the marketplace.
Implement early definitions of the roles and responsibilities for product and technical leadership. Deliver the message that they are in this canoe together and thus must work together to execute against the top priorities.
Make small obvious changes to execute against the top priorities, even if it means that just a few people or teams are altered. This may need to change again after Agile training, but since we want to promote focus on the priorities, this is the right place to start.
Again, this should be done with the top priorities in mind. Assigning and define a product and technical lead role for these key initiatives. Also look at assigning and defining roles like the Scrum master or program manager, test or automation lead, release management/DevOps, and other key roles needed to deliver different features to the marketplace.
Create and communicate training plans for leadership as well as the teams that align with the team re-boot or Scaled Agile transformation
Develop a process for providing transparency about progress around the key priorities. Some examples include:
Finally, celebrate your wins early and often. This promotes value delivery and is another way to make progress clear to teams. Just realize that if you mind the gap, your organization will have a lot to celebrate!
My journey in Agile began in 2006 when I was an employee leading a traditional PMO and production support team. Our team had already revised a lot of our development processes to follow a clear “waterfall” process with stage gates and sign-offs. We had also spent a lot of time defining and supporting roles and responsibilities, making clear each team’s priority. Our efforts resulted in an increase in productivity, trust, and predictability.
Then we hit a wall.
I embarked on a campaign to leverage a framework I had read about for a few years called Agile (specifically Scrum). It took about three months to receive buy-in and support. We started on an Agile transformation that ultimately trained 12 teams over the course of one year. Even by my measures today — and feedback from others who look back on that time — it was an impressive transformation.
Now, as a consultant and business owner who guides companies through their Agile and Scaled Agile transformations, I think back to that time. I think about what primary ingredients that first transformation had that made it feel so different from what I see in many organizations today.
Agile was new for everyone. No one, that I was aware of, had received past Agile training. We were learning something new together.
We had leadership support. Yes, it took work to garner the support, but we did not begin the process of training and transformation until the head of engineering, product, and even the president of the company were on board with our efforts. We then moved on to get support from the engineering and product managers before training teams. Support didn’t stop with funding training: it continued through monitoring and managing the metrics, alignment of employee goals, and ongoing support of the teams.
We generated excitement and participation. Our first group to “go Agile” was a group of three teams building a brand new product. This group was having trouble getting off the ground. Their testimonial and early success after training inspired others to volunteer.
Most organizations will have already received some level of Agile training. Unfortunately, it does not usually happen among the same team members or even within the same organization. Another problem lies in not seeing or learning from many ineffective uses of the Agile framework.
This is not a new issue. Leadership often struggles to support teams or simply isn’t interested in providing the necessary guidance. The use of Agile has gone stale. Organizations are “sort-of Agile,” but there is a gap between where they are and where they are meant to be.
This, of course, is where the solution lies.
My experience is that an organization of 100-300 tech and product people will take at least 12-18 months to work through an Agile reboot or scaled Agile implementation. Larger organizations may take even longer. Luckily, short-term alignment and progress don’t have to wait. Here are 7 tips I recommend to organizations:
It is important in any organization for teams to understand and share the same priorities. Additionally, you want to make sure that the work is clearly defined using acceptance criteria and that scope will deliver some increment of value to the marketplace.
Implement early definitions of the roles and responsibilities for product and technical leadership. Deliver the message that they are in this canoe together and thus must work together to execute against the top priorities.
Make small obvious changes to execute against the top priorities, even if it means that just a few people or teams are altered. This may need to change again after Agile training, but since we want to promote focus on the priorities, this is the right place to start.
Again, this should be done with the top priorities in mind. Assigning and define a product and technical lead role for these key initiatives. Also look at assigning and defining roles like the Scrum master or program manager, test or automation lead, release management/DevOps, and other key roles needed to deliver different features to the marketplace.
Create and communicate training plans for leadership as well as the teams that align with the team re-boot or Scaled Agile transformation
Develop a process for providing transparency about progress around the key priorities. Some examples include:
Finally, celebrate your wins early and often. This promotes value delivery and is another way to make progress clear to teams. Just realize that if you mind the gap, your organization will have a lot to celebrate!
My journey in Agile began in 2006 when I was an employee leading a traditional PMO and production support team. Our team had already revised a lot of our development processes to follow a clear “waterfall” process with stage gates and sign-offs. We had also spent a lot of time defining and supporting roles and responsibilities, making clear each team’s priority. Our efforts resulted in an increase in productivity, trust, and predictability.
Then we hit a wall.
I embarked on a campaign to leverage a framework I had read about for a few years called Agile (specifically Scrum). It took about three months to receive buy-in and support. We started on an Agile transformation that ultimately trained 12 teams over the course of one year. Even by my measures today — and feedback from others who look back on that time — it was an impressive transformation.
Now, as a consultant and business owner who guides companies through their Agile and Scaled Agile transformations, I think back to that time. I think about what primary ingredients that first transformation had that made it feel so different from what I see in many organizations today.
Agile was new for everyone. No one, that I was aware of, had received past Agile training. We were learning something new together.
We had leadership support. Yes, it took work to garner the support, but we did not begin the process of training and transformation until the head of engineering, product, and even the president of the company were on board with our efforts. We then moved on to get support from the engineering and product managers before training teams. Support didn’t stop with funding training: it continued through monitoring and managing the metrics, alignment of employee goals, and ongoing support of the teams.
We generated excitement and participation. Our first group to “go Agile” was a group of three teams building a brand new product. This group was having trouble getting off the ground. Their testimonial and early success after training inspired others to volunteer.
Most organizations will have already received some level of Agile training. Unfortunately, it does not usually happen among the same team members or even within the same organization. Another problem lies in not seeing or learning from many ineffective uses of the Agile framework.
This is not a new issue. Leadership often struggles to support teams or simply isn’t interested in providing the necessary guidance. The use of Agile has gone stale. Organizations are “sort-of Agile,” but there is a gap between where they are and where they are meant to be.
This, of course, is where the solution lies.
My experience is that an organization of 100-300 tech and product people will take at least 12-18 months to work through an Agile reboot or scaled Agile implementation. Larger organizations may take even longer. Luckily, short-term alignment and progress don’t have to wait. Here are 7 tips I recommend to organizations:
It is important in any organization for teams to understand and share the same priorities. Additionally, you want to make sure that the work is clearly defined using acceptance criteria and that scope will deliver some increment of value to the marketplace.
Implement early definitions of the roles and responsibilities for product and technical leadership. Deliver the message that they are in this canoe together and thus must work together to execute against the top priorities.
Make small obvious changes to execute against the top priorities, even if it means that just a few people or teams are altered. This may need to change again after Agile training, but since we want to promote focus on the priorities, this is the right place to start.
Again, this should be done with the top priorities in mind. Assigning and define a product and technical lead role for these key initiatives. Also look at assigning and defining roles like the Scrum master or program manager, test or automation lead, release management/DevOps, and other key roles needed to deliver different features to the marketplace.
Create and communicate training plans for leadership as well as the teams that align with the team re-boot or Scaled Agile transformation
Develop a process for providing transparency about progress around the key priorities. Some examples include:
Finally, celebrate your wins early and often. This promotes value delivery and is another way to make progress clear to teams. Just realize that if you mind the gap, your organization will have a lot to celebrate!
.png)
