Groovy Spotlight: Julie Ho, Agile Coach
Meet Julie Ho, Agile Coach on Ordergroove’s Product team. We asked Julie some questions about what it’s like working at OG and how she’s seen Agile methodology impact the Product and Engineering teams. Read more to hear Julie’s take on life at OG!
We’re hiring for the Product team and more — check out our career page for a full list of open roles.
What is Agile methodology, and why is it important for organizations like Ordergroove?
Agile software development is a term applied to iterative software development. This framework holds the Agile Manifesto, both the values and principles, at its core. At Ordergroove, the majority of the product development teams use Scrum.
Scrum is arguably the most widely used Agile framework that is used to solve complex problems. The teams I work with use the three pillars of empiricism that form the foundation of Scrum Theory: Transparency (our work product, progress, and process is visible at all times), Inspection (we review our work frequently), and Adaptation (we adjust our process when we see there is room for improvement). These three pillars enable the teams to get feedback on their software as quickly as possible, fold it back into their development cycle, and adjust to improve how they work together.
Ordergroove decided that it was important for our product management and engineering organizations to be able to move and learn as rapidly as possible, and saw that a dedicated Agile coach was instrumental to product management and engineering success, and subsequently company success. The company was large enough at the time to benefit from a more disciplined approach.
Over your time at OG, how have you seen Agile impact our Engineering and Product teams?
These teams work better together — within themselves, with each other, and across other departments. At the product management and engineering organization level, we use kick-off meetings at the start of the quarter to get everyone aligned with the initiatives we plan and the outcomes we hope to achieve in order to meet company OKRs. The product managers and dev team managers then inspect every 30 days throughout the quarter to share progress on those initiatives. We struggle less now with inter-team dependencies. These are not Scrum events but additional meetings that help our process, and we only arrived at using these meetings after trying other ways to increase Transparency (creating a card wall of all teams’ epics didn’t work after two attempts).
At the team level, they each have a wonderful, can-do spirit where collaboration is constant — I see engineers lean over to another’s desk to have a conversation about a pull request, or stay on video chat with remote colleagues instead of just using Slack or email. My teams joke with each other and share GIFs, but they aren’t afraid to hold different, often strong, opinions about how to implement a feature or what’s best for the architecture — they disagree but will commit to each other for what’s best for the company and our clients.
At the individual contributor level, I have seen OG’s engineers grow in confidence and improve peer-to-peer relationships; some have stepped up one level into senior engineer roles. I have seen resentments melt away because one engineer has the courage to say to another, “I felt this way when my changes were overwritten,” and a better working relationship results because they now pair program. A new senior engineer suggested to his teammates the practice of writing one-pagers when they started to decompose a really complex epic. His team adopted it and found it came in handy a few sprints later when one member was away on vacation and returned to refinement sessions without missing too much. All of these positive outcomes can happen because we regularly talk about how we work together at team retrospectives (Inspecting and Adapting).
Additionally, I stress the importance of being able to use plain language to talk about the business value of the work they deliver, and not just the technical “how we put it together with this array,” so that stakeholders including leadership can provide engineers with feedback at sprint reviews (more Transparency). My product managers now use job stories, in addition to user stories, when putting down requirements for their teams. Previously they relied upon the persona-driven user story and would often write, “As Ordergroove, I want to …” resulting in some vague set of requirements and no clear driver. Job stories, because they are event driven, would apply to any persona at Ordergroove, and have been particularly useful for my platform teams.
What do you think it takes to be successful at OG?
People who succeed at Ordergroove are those who are willing to learn and willing to do what’s best for the company, the team, and then themselves, based on what they have learned.
You read about hiring people with these qualities in management books and blog posts and how much value they will add to your company. But it is true and it is hard to do, which is why I am not in People Ops! But I am grateful when we do hire people with these qualities, or I have team members already present with these qualities.
You’ll hear me say: “My job is to make you work better together, not to make your job easier, because work is hard.” Because the product management and engineering organization uses Scrum every day, we understand when we do something well and we can repeat it, and we understand when we don’t do something well so we can stop doing it. This is why I believe my teams are successful at Ordergroove: We keep learning. And we use what we learn.
How did you get started with Agile?
I was a project manager before I became a Scrum master, so I was heavy into creating and managing project timelines, work breakdown structures and Gantt charts. It was challenging but not the right kind of challenge for me the more I worked on client projects. The founder-CEO of the first startup I worked at many, many years ago, who hired me to be his project manager on a big account, gave me Agile Software Development with Scrum (the seminal book by Ken Schwaber and Mike Beedle) and told me, “You need to read this, you would be good at this,” and he was right. Getting the Scrum certification is one thing, but practicing with real, live teams is another — it’s so much better! Now, I am fortunate enough to be an Agile coach, and I have a coach working with me, too, because I have to keep learning and keep “the student’s mind.”
Fun fact about yourself?
I’ll give you two: One, I’m all about nail art, so much so that I change my manicure every other week. My nail studio recently featured my hand on their social media which was exciting.
Two, one of my teams uses my name as a superlative. When my product manager said to his lead architect, “That’s the Juliest user story you ever wrote” — because the architect wrote a user story with a clear motivation and a clear outcome, two things I stress about user story writing — I was never more proud of them as their coach. They got me a baseball cap to commemorate that moment.
