A lire sur: http://www.techrepublic.com/blog/project-management/applying-agile-concepts-at-homeaway/4609?tag=nl.e053
HomeAway is a publicly-traded company (AWAY: Nasdaq)
in the Internet retail space, focused on web-based vacation rentals.
Since its IPO in June of 2011, HomeAway’s stock has languished, dropping
from its IPO price of $35 to its current $24.56. Still, HomeAway has
increased its revenue 24% over last year, and has demonstrated increased
renewals and new listings and found other sources of revenue beyond the
core consumer travel offerings.
More
importantly for our conversation, HomeAway is a prime example of an
enterprise that has embraced agility and made it a core value of the
company. From the CEO through the executive suite and into the ranks of
developers, agile concepts have permeated the business model of
HomeAway, and enabled its growth in new product offerings and its
responsiveness to customer needs.
TechRepublic chatted with Jack Yang, HomeAway’s Vice President of Engineering, to see what we could learn about applying agile concepts to a growing, public company. Jack is responsible for managing the development teams that focus on the traveler experience, including the network of HomeAway sites travelers use to find properties as well as the applications used to plan trips. He is also the primary software development process evangelist within the company and mentors new teams on agile development.
TechRepublic: How have agile ideas migrated in your organization from the software development team to the strategic part of the business?
Jack: One of the key lessons we’ve learned at HomeAway about rolling out agile was the need to socialize and not strictly evangelize. People need to be shown success before they’ll be interested in asking for help. My first rule regarding introduction of agile into any part of the business is that the people have to come and ask me first. That really internalizes the need for change.
Recently, we’ve been struggling with a roadmap process. We’ve been doing a lot of upfront planning, only to find that the very next month, the entire core of the plan gets totally rearranged. We did this repeatedly. Every time we’d bemoan the fact that it was a long and unfruitful process. We found as we reorganized recently, and empowered many of our product people to be mini-CEOs of their products, giving the development person along with the product manager more of a sense of ownership of their product, they started asking for more help.
From attending various conferences, it seems there’s an idea circulating about steering instead of planning. You set a vision for what you want in three years and where you want to go with it, but you need to be fluid enough to stop at many checkpoints. Not just quarterly, but maybe even monthly, to see how you’ve progressed, how that changes your playing field, and whether you’ve had environments progress so that a competitor has become very relevant to you, and you need to answer their challenge and steer the boat to respond.
At the same time you need to be doing this gut check where we ask ourselves what we are aiming for over these three years, and whether that is still a valid concern for us. If so, great, we’re going to keep going and deliver as promised, with some incremental change to our roadmap. Traditionally, businesses want to cram everything into a development plan, and commit its team to hard dates. We’ve gotten our business to think in other terms. We haven’t crammed the development team full, we’ve left some spare capacity. With that spare capacity, you’ll address those backlog items that aren’t specifically committed, but the team will just pull those in and get them done.
TechRepublic: It sounds as if the steering process you describe becomes a substitute for a traditional strategic planning process, in which a bunch of executives go offsite for a week and come back with a grand strategic plan that ends up losing its relevance by the time it’s unveiled. Is that an accurate comparison?
Jack: I can’t think of a single person who enjoys a multi-day offsite planning process. Any alternative to that is something to be looked forward to. The difficulty for us was that there was no alternative in which product development, leadership, and development could get on the same page.
We do in the development organization a quarterly review that rolls up our accomplishments and what we didn’t accomplish. Once we moved to retrospectives throughout the business and not just in development, it became more clear that we need to iterate and not just go through this false planning. Every single time the roadmap would fail or change, you get more and more evidence that we shouldn’t have done it that way.
Also important was getting development successful at this so we could show that we could iterate toward a result. For example, on one team that was applying scrum we reached a point where the business team was yelling, “Stop, stop, we can’t keep up with how fast you’re doing stuff! We can’t get the requirements ready for the next sprint planning.” For our lean kanban team, the question from product marketing is no longer, “When are you going to release this code?” or “When are you going to release this feature?” The question now is, “When is that going to reach the ready state for ‘ready to go’?” They want to know when features are going to hit the queue, because they know once features hit the queue, it’s a matter of days before it gets released. That shift in mentality was critical for us. Demonstrating that continuous release could be done, and reapplied to other business areas, made it a no-brainer. They realized, “This is not secret sauce, this is not that difficult a concept, you shouldn’t have to read a book to get these agile ideas.”
TechRepublic: If you were to survey the executive leadership team at HomeAway about what agile means to the company and what the journey to agile meant to HomeAway, how do you think they’d respond?
Jack: Our CEO knows we’re an agile shop and supports us. He is out there promoting our company and doesn’t have to see the day-to-day tactical. Our CTO and CPO are very aware of this agile evolution; they’re the ones who empowered our subteams and developed this idea of product line teams. Instead of a traditional top-down model, our product line teams include product people, [a] development person, [a] QA person, [a] product marketing person, small groups of empowered people who are in charge of a specific facet of our product. It’s very liberating and cool to know that at the C-level we have people that are proponents of, and have actively set up, fertile grounds for us to sprout from.
TechRepublic: So they’re not down in the details of the agile methodology but they understand the impact agile has had on the company…
Jack: Six years ago our CTO came to me and said, “I’ve studied up on this scrum thing, this agile thing, we need to get this implemented!” He left the details to us. Our CPO and our COO are newer, but they came from agile backgrounds. They looked at our processes, did a refinement, and added some new things. It’s not that they got the benefit and said, “Oh wow, agile is great.” They knew what agile was and said, “Go forth and do it!”
Read part two of our interview with HomeAway’s Jack Yang.
Takeaway: HomeAway’s
VP of Engineering Jack Yang comments on how the company embraced agile
and made it a core value, the real business advantage of agile thinking,
and more.
More
importantly for our conversation, HomeAway is a prime example of an
enterprise that has embraced agility and made it a core value of the
company. From the CEO through the executive suite and into the ranks of
developers, agile concepts have permeated the business model of
HomeAway, and enabled its growth in new product offerings and its
responsiveness to customer needs.TechRepublic chatted with Jack Yang, HomeAway’s Vice President of Engineering, to see what we could learn about applying agile concepts to a growing, public company. Jack is responsible for managing the development teams that focus on the traveler experience, including the network of HomeAway sites travelers use to find properties as well as the applications used to plan trips. He is also the primary software development process evangelist within the company and mentors new teams on agile development.
TechRepublic: How have agile ideas migrated in your organization from the software development team to the strategic part of the business?
Jack: One of the key lessons we’ve learned at HomeAway about rolling out agile was the need to socialize and not strictly evangelize. People need to be shown success before they’ll be interested in asking for help. My first rule regarding introduction of agile into any part of the business is that the people have to come and ask me first. That really internalizes the need for change.
Recently, we’ve been struggling with a roadmap process. We’ve been doing a lot of upfront planning, only to find that the very next month, the entire core of the plan gets totally rearranged. We did this repeatedly. Every time we’d bemoan the fact that it was a long and unfruitful process. We found as we reorganized recently, and empowered many of our product people to be mini-CEOs of their products, giving the development person along with the product manager more of a sense of ownership of their product, they started asking for more help.
From attending various conferences, it seems there’s an idea circulating about steering instead of planning. You set a vision for what you want in three years and where you want to go with it, but you need to be fluid enough to stop at many checkpoints. Not just quarterly, but maybe even monthly, to see how you’ve progressed, how that changes your playing field, and whether you’ve had environments progress so that a competitor has become very relevant to you, and you need to answer their challenge and steer the boat to respond.
At the same time you need to be doing this gut check where we ask ourselves what we are aiming for over these three years, and whether that is still a valid concern for us. If so, great, we’re going to keep going and deliver as promised, with some incremental change to our roadmap. Traditionally, businesses want to cram everything into a development plan, and commit its team to hard dates. We’ve gotten our business to think in other terms. We haven’t crammed the development team full, we’ve left some spare capacity. With that spare capacity, you’ll address those backlog items that aren’t specifically committed, but the team will just pull those in and get them done.
TechRepublic: It sounds as if the steering process you describe becomes a substitute for a traditional strategic planning process, in which a bunch of executives go offsite for a week and come back with a grand strategic plan that ends up losing its relevance by the time it’s unveiled. Is that an accurate comparison?
Jack: I can’t think of a single person who enjoys a multi-day offsite planning process. Any alternative to that is something to be looked forward to. The difficulty for us was that there was no alternative in which product development, leadership, and development could get on the same page.
We do in the development organization a quarterly review that rolls up our accomplishments and what we didn’t accomplish. Once we moved to retrospectives throughout the business and not just in development, it became more clear that we need to iterate and not just go through this false planning. Every single time the roadmap would fail or change, you get more and more evidence that we shouldn’t have done it that way.
Also important was getting development successful at this so we could show that we could iterate toward a result. For example, on one team that was applying scrum we reached a point where the business team was yelling, “Stop, stop, we can’t keep up with how fast you’re doing stuff! We can’t get the requirements ready for the next sprint planning.” For our lean kanban team, the question from product marketing is no longer, “When are you going to release this code?” or “When are you going to release this feature?” The question now is, “When is that going to reach the ready state for ‘ready to go’?” They want to know when features are going to hit the queue, because they know once features hit the queue, it’s a matter of days before it gets released. That shift in mentality was critical for us. Demonstrating that continuous release could be done, and reapplied to other business areas, made it a no-brainer. They realized, “This is not secret sauce, this is not that difficult a concept, you shouldn’t have to read a book to get these agile ideas.”
TechRepublic: If you were to survey the executive leadership team at HomeAway about what agile means to the company and what the journey to agile meant to HomeAway, how do you think they’d respond?
Jack: Our CEO knows we’re an agile shop and supports us. He is out there promoting our company and doesn’t have to see the day-to-day tactical. Our CTO and CPO are very aware of this agile evolution; they’re the ones who empowered our subteams and developed this idea of product line teams. Instead of a traditional top-down model, our product line teams include product people, [a] development person, [a] QA person, [a] product marketing person, small groups of empowered people who are in charge of a specific facet of our product. It’s very liberating and cool to know that at the C-level we have people that are proponents of, and have actively set up, fertile grounds for us to sprout from.
TechRepublic: So they’re not down in the details of the agile methodology but they understand the impact agile has had on the company…
Jack: Six years ago our CTO came to me and said, “I’ve studied up on this scrum thing, this agile thing, we need to get this implemented!” He left the details to us. Our CPO and our COO are newer, but they came from agile backgrounds. They looked at our processes, did a refinement, and added some new things. It’s not that they got the benefit and said, “Oh wow, agile is great.” They knew what agile was and said, “Go forth and do it!”
Read part two of our interview with HomeAway’s Jack Yang.
Aucun commentaire:
Enregistrer un commentaire