Last week, we hosted an agile adoption case study webinar. We invited Si Alhir and the AutoVIN team to speak about their experience as their company ventured into an agility transformation. The team members share their perspectives from their different roles in the journey, and offer specific actionable lessons they’ve learned that you can leverage in your own agile transformation.
Watch the full webinar recording here.
There was so much great content in the discussion that we didn’t manage to have a longer Question & Answers period. Si Alhir and his team took the time after the webinar to answer some additional questions. If you have more, please post them in the comments section!
Questions & Answers
Q. What was the initial planned timeline for the (AutoVIN’s) Platform project?
A. As the AutoVIN solution/platform is continuously evolving, there was not an “initial planned timeline” per se, but the objective of maximizing the efficiency and effectiveness of the team, capitalizing (between ADESA and AutoVIN) on the vehicle inspection and reporting platform, and integrating a more-agile team with other less-agile teams (and world).
Despite that there were no initial planned timeline, circumstances forced a timeline and change in scope. Being agile has allowed this to happen more easily because features were prioritized from highest to lowest according to usage and broken into smaller amounts of work.
Q. Was User Experience design part of this process? or only back-end work?
A. Usability / User Experiences is a facet of the Product Owner role and Define-Detail perspective (of the Define-Detail, Build, and Test aspects of the Team) was continuously considered. User experience was part of the process and was essential in the adoption of the rollout plan for the new platform. Technology should make it easier for the user.
Q. Can agile methodologies be used in bigger teams? Is there a team size limit? For example, in a company of about 250 employees?
A. Agile adds flexibility and improves communication through usable software. The flexibility comes from the smaller increments of work that allow the features to by more easily aligned with the schedules of other teams.
Agile and Agility readily apply to larger and smaller teams. Scaling is not problematic when approached and designed deliberately. See the car.com case study for more information.
Q. How can the use of virtual project management tools or issue tracking tools help in an agile transformation journey? (other than helping teams working remotely). Especially for different teams that are used to work on its own domain and has it’s own planning board of activities?
A. The virtual project planning tool should be able to make changing plans an easier task. Priority can change due to the many influences on a product/project and with any transformation journey there is a discovery process that should not be hindered by tools.
Tools are valuable when they advance (versus impede) healthy human dynamics (well-being) and don’t introduce or perpetuate unhealthy human dynamics in support of overall performance. The crucial question about tools is “why” (benefits and detriments), the other four Ws (who, what, when, where), and “how”.
Q. I understand you don’t want to stifle creativity in the software development process, but at where do you draw the line, so you avoid doing R&D while on a project? I’ve tried to keep R&D outside of the project.
A. R&D happens throughout the project. Some may be up front to get comfortable with the scope but an important part of the process is to allow yourself time to plan ahead. As with anything creative, it requires outside inputs or situations and the best way to find these can be through implementing and experiencing the results of the product. The best validation of a need is through use, just keep the features light to limit the risk.
The crucial question concerning Agility is “what is value” (and how is it discovered and delivered). Once “value” is recognized, all things are balanced against it, for example, how much capacity we have, how much value is needed now versus later, and how much can we offered to focus on R&D now versus later, etc. Technology research & product development and market research & product design are partners in the overall discovery and delivery cycles around value. The Value questions is paramount!
Q. If you could offer one key recommendation to others interested in becoming more agile or achieving greater agility, what would that be?
A. AutoVin team: “Go all in, don’t give up early or alter the process at first. It can be difficult to improve and enforce positive habits/behavior.”
Si: One key recommendation is focus on Agility (not merely Agile Development), and don’t get “caught up” in dogma!
Q. What was the most “surprising” thing about your journey?
A. The most surprising part was how much the process aided in the team dynamics and improved morale.
Q. If you could do one thing differently what would that be?
A. Starting the journey earlier. It may have changed the decision around the office closing.
Q. What was “easier” than expected? What was more difficult than expected?
A. Easier: Starting our first sprint/iteration after iteration 0 (Getting to work without a thorough plan and trusting ourselves).
Difficult: Working with a less agile enterprise. Everything seems like an emergency and outside processes seem slow. It requires more planning to account for the different paces (heartbeats) of a less agile organization.
Click here for the slides of the webinar.
Tags: agile, Agile Adoption, agile adoption case study, agile case study, Agile product management, Agile project management tool, agile scaling, Agile Software, agile transformation, agility, automated vehicle information network, autovin
