Easy Agile Podcast Ep.5 Andrew Malak, Chief Product Officer at Spaceship
"I really enjoyed my conversation with Andrew Malak. We talk integrating agile techniques and tips on how to achieve a culture of accountability"
Andrew is a firm believer that the customer trusts your business by joining, and you have an obligation to repay that trust by helping them achieve their outcomes.
Enjoy the episode!
Transcript
Teagan Harbridge:
Welcome to another episode of the Easy Agile Podcast. I'm Teagan, head of product here at Easy Agile. And we've got a really exciting guest on the show today, Andrew Malak from Spaceship. He's the chief product officer. Andrew is a true believer in creating products and experiences that solve customer problems. He believes that the customer trusts your business by joining, and you have an obligation to repay that trust by helping them achieve their outcomes. In his current role, Andrew aims to help people take control of their wealth from a young age, educating good money habits and helping people invest where the world is going. Andrew is a family man who loves his time with his wife and children. And believe it or not, he uses agile techniques in his personal and professional life. Andrew is an economics geek. He plays and coaches soccer, football. He's a big Liverpool supporter, loves to travel, loves amazing architecture, and loves working with children.
Teagan Harbridge:
There were so many takeaways from my chat with Andrew that I really struggled to pair it down to three. But if you say tuned, here are some of the things that you're going to learn from our chat with Andrew. Why we should stop using the term agile transformation and start calling it an agile evolution. Why it's important to be open-minded to our own limitations so to break the old mindset of protecting original scope. And tips on how to achieve a culture of accountability. So I hope you enjoy. Andrew, can you tell me a little bit about Spaceship?
Andrew Malak:
Oh, fantastic. Well, thank you very much for, first of all, having me, Teagan. Spaceship is a business that's on a journey to make good money habits and investing accessible to all people. So what we look for is trends to do with industries or companies who are building the future of both industry or economies. We invest in them for the longterm, we break down barriers of entry for people, we give them a fee-free product under $5,000, no minimum investments. It's really easy to sign up. You simply download an app and you sign up and make one product selection decision, and you're done. You can start investing on autopilot. We allow you to also invest your superannuation in a not too dissimilar way.
Teagan Harbridge:
So tell me a little bit about who your target customer is, then. Because it seems like you're trying to make something quite complicated accessible for maybe first time investors.
Andrew Malak:
Well, you're absolutely right. There's a niche segment of people out there at the moment, millennials or even gen Zs, that we just don't think have been well serviced by the incumbents. And what we're trying to do is resonate with these young people as much as possible. We're trying to reduce industry jargon and really make things simple to them, because investing doesn't have to be complex. It's really about a lot of discipline around, if I can manage my personal P&L, or money in, money out, then I can create a cash buffer that can go into my assets column on my balance sheet. That's really what we're trying to do. And that kind of language, if we can get it right, can really simplify things that have typically been in the hands of financial advisors and accountants and give it back to everyday Australians who are starting out in their investment journey.
Teagan Harbridge:
Yeah, awesome. And you've been on quite a journey before landing in the FinTech space as the Spaceship CPO. So can you tell me and our audience a little bit about what that journey has looked like?
Andrew Malak:
Oh, where do I start? If you asked a graduate Andrew Malak what he'd be doing now, I don't think I would've been speaking about this because at that point in time in my career I didn't know this space would actually be around, if that makes sense. So I'll go back to my younger years, and I always thought I was going to be an architect. I had this fascination with bridges and I wanted to design things and see them come to life. And let's just say that I do that in different ways right now, but I started out working in CommSec on the trading floor. I moved on to work as a business analyst, and that's where I started my critical thinking into how businesses work and how things can be made more efficient.
Andrew Malak:
I dabbled in teaching for a little bit, I taught high school economics and religion for a little bit. And then I eventually landed in a product role at St. George Bank prior to the merger with Westpac. At that point in time, the light bulb really came on. I realized, "Hey, I like creating things. I like to change things. I don't like to just do things," if that makes sense. And that wondering mind that doesn't like the conform was finally let loose, if that makes sense. And I haven't stopped enjoying it. I loved my time at Westpac, made lots of friends, worked on really cool, successful projects, and implemented lots of things that had great results. Worked on lots of things that have failed miserably and learnt a lot out of that. And when the opportunity at Spaceship started to surface late last year, it was just too good an opportunity to not really come in and have a go. So yeah, it's been quite the journey.
Teagan Harbridge:
Yeah, wow. And I love a good failure story. And you said you've had lots. Can you think, just off the top of your head, what one of those big failures has been?
Andrew Malak:
Where do I start? I think our first attempt at taking a digital experience to allow customers to acquire a product online was quite a failure that taught us a lot. We basically took the systems that our back office staff used and just made it available to customers. And the real good learning out of that is there was a lot of traffic and a lot of demand, but not enough completion ever. And the best learning that came out of that... This is back in 2006, so internet speeds were just starting to pick up. Broadband was starting to go mainstream and customers' trust around doing more transactions that used personally identifiable data was starting to normalize at that point in time. Up until then, people quite reserved thinking, "I'm going to lose my personal data," et cetera. So when we decided to do that, we saw that there was a lot of demand but we quickly came to the realization that we used to train staff for four to six weeks on how to use the systems before they knew how to service customers using them.
Andrew Malak:
But then we've deployed it into production for customers to self-service and realized quite quickly that the experience for customers had to be much more guided than the experience for a staff member. This is where the evolution of usability or design thinking started to come in. We started thinking of, "Well, how do we make these things so easy that a first-time user can go end to end and not encounter friction?" And this is where our understanding of design principles, customer testing using verbatim and anguage that can resonate with a first-time user becomes critical to the execution. It's not just good systems but it's good user experience sitting on top of systems.
Andrew Malak:
That's probably the one that resonates with me the most because I've held that to a very high regard throughout my whole career. Now everything I do I think of, "Where's the friction? How do we make sure there's no friction? What's the customer going to feel throughout this experience? How are we creating unnecessary anxiety in that experience for the customer, and how do we move that away? How do we become more transparent but still be simple?" And yeah, that's probably the one that resonates the most.
Teagan Harbridge:
Seems like a tremendous learning opportunity early enough in that project and something that's stuck with you since, so great learning opportunity.
Andrew Malak:
Absolutely.
Teagan Harbridge:
We've got a ton of customers who are at all stages of their agile transformations, and I know that this is something that you've had experience with if we go back to your St. George, Westpac days. Can you give our audience any tips or stories that you encountered when you were going through those agile transformations? What lessons can you share with our audience?
Andrew Malak:
Oh, I have lots of lessons to share, actually.
Teagan Harbridge:
This is what I love.
Andrew Malak:
Look, I like to position it more as agile evolution more than agile transformation because no matter what you try to do, you're not just going to drop waterfall and become agile next morning. Honestly, I've seen so many attempts and every single time I see that the graduality of the change is a better predictability of the final outcome that you're going to land. So ultimately the Holy Grail that everyone's aspiring to is that, as a leader, you can rock up to a team stand up unexpected and then, without being told who is in what role, who the product owner is, who the engineer is, who the QC is, who the designer is, it becomes hard for you as the leader to work out who's who because at that point in time the team is so well converged on customer outcomes that they will self-organize themselves around what each person needs to do.
Andrew Malak:
And most of the language being used is really around, what are we trying to define the customer? What's the best thing to do within the capacity that we have to deliver this feature to market as quickly as possible, capture value for the customer and the business as much as possible? This takes a long time to get to, where you can start normalizing to a standardized, common set of goals, common cadence, and common ways of working. And I think it's ultimately about how much empowerment you can give people and how much as a leader you can relegate yourself in the background to allow them to work it out themselves as long as you're coming in and nudging things along the way and helping people course correct along the way. So the good news is that I actually think at Spaceship, we're pretty close to getting there.
Andrew Malak:
We have been running scrum and we have been running sprints for a long time, but it has been largely ceremonials. But over the last quarter, we've done a really good job at embedding more cross-functional people into these teams. But the goal for us is that now we feel like our throughput has actually increased and that the constant flow of information between the teams is becoming more natural and there is actually less ambiguity between the teams around, "All right, we built it this way. The API is no longer consumable. It doesn't fit what we're trying to do from our front-end and there's less back and forth." So we can really see that the amount of friction between persons in the team is really starting to reduce dramatically and we're starting to see that throughput really increase. Having said that, the best way to go about an agile transformation is just get started.
Andrew Malak:
You can sit and plan out things and plan towards utopia as much as you want or you can actually just get going. So when I say by get going, I say you have to start by getting buy-in from all the leaders of the different cross-functional teams, because if you don't have that buy-in at the leadership level, it's just not going to work because there's going to be blockers, there's going to be escalations. And if all these things result in conversations around, "Should we keep doing this?" Or, "Hey, maybe this is not the right thing to do." That needs to be off the table really early on and it needs to be a total commitment at the leadership level that we're going to make this work and whatever we encounter we're just going to fix forward. Once you have that commitment at the leadership level, you need to very clearly define the values that the team is going to be handed to work with, because agile itself, it's not a process, it's a set of values that the team needs to just take and start working with.
Andrew Malak:
So we could go and rattle individuals and interactions over processes and tools or working software over comprehensive documentation. Well, give these to the team and they're going to say to you at day one, "We can't go to all of that straight away." So they might actually say that day one, "We're still going to need some documentation because we're not comfortable yet. We don't understand the language of the other people in the scrum team well enough to be able to go and actually code off the back of a conversation." But by the 10th sprint, the 20th sprint, that misunderstanding of what the product owner wants or what the designer is trying to achieve in an experience starts to become embedded in the mind of the engineer.
Andrew Malak:
The engineer understands the customer a lot more, and then you can make do with less process and less documentation and less negotiated outcomes and more commonality across the team. The other thing that then starts to kick in at that stage is that ability of the team to pivot in response to a change and not see that as a threat to what they're trying to achieve. The old ways of working was, define that scope, protect that scope, and not let things disturb that scope, whereas if you're halfway through a project and you get some really good information that tells you that maybe you are not on track to achieve a good outcome, you should be welcoming that. And the team itself in the beginning is going to find that an irritation, but over time they'll become more comfortable with pivoting off the back of new information.
Teagan Harbridge:
Yeah. It's a big mindset shift. I was just having a discussion today about, where does being agile and being reactive, where's that line in the middle. And when does taking information and pivoting because you think something will be better, when can we break that mindset of, "Oh, we're just being reactive?" No, we're being responsive.
Andrew Malak:
Yeah, yeah. And look, I think the word reactive itself naturally has a negative connotation to it, but agility in mindset allows you to flip that on its head and say that no one can work things out in totality to 100% of what's possible, so being open-minded to our own limitations first and foremost allows us to acknowledge that when new information comes in, it is because we didn't think through the solution 100%, but let's also be okay with that because no one can. So I think it's flipping on its head and acknowledging it upfront and saying that this is going to happen, but when it comes we will assess the information we have with the capacity we have with how far progressive we are and make a decision that's right for us, for the customer, and for what's possible.
Andrew Malak:
So I take it as the more information you get along the way, the more reinforcement of, are you doing what's right or should you pivot and change at that point in time? The other thing that happens really early on is that if you as a leader can create a really clear vision around customer outcomes and establish your first cross-functional team and hand over that vision to the team, it becomes theirs. Don't hand over the backlog to the team. Don't give them a ready backlog, just give them the vision and then tell them, "You guys work out what your backlog looks like." When they come up with their own backlog, as long as you as a leader don't see that it's just a list of Hail Marys in it and there is a fair bit in there that is well spread out between hygiene things, strategic things, and a few moonshots and the balance is right, if the team has come up with their own backlog, the motivation they have to build their own ideas just goes through the roof.
Andrew Malak:
And that's what you want to achieve. You want to achieve clarity that the work fits with the vision and the motivation that you get out of the backlog being created by the team itself gets you that throughput enhancement. The other thing that you're going to struggle with really early on is chunking things down to fitting within the sprint cadence. I think that's one that's often been my biggest challenge when moving towards agile practices early on. Typically in the first few sprints, you always have overruns and things don't complete in the sprint because we end up thinking we can do more than we can and it takes us a while to work out, in wrapping up something that becomes shippable in a sprint, you probably take a little bit less in that sprint because you've got to test it or you've got to do a release in that sprint, or you're going to do a PIR in that sprint, or you're going to do a lot of retros in that sprint. Start to sort of formulate what you're going to take through the next planning cycle.
Andrew Malak:
So you've got to budget to that capacity, and I'll find that teams underestimate the magnitude of that work. So be okay with that. Overruns in the first few sprints don't mean you've failed, it means you're learning how to plan better. And then make sure your retros and your pivot off the back of that into your next planning sessions is taking information that is now new to you, and making sure you're working with it. I think as the leader, though, you have to set the expectations that teams can make mistakes and that it's a safe environment.
Andrew Malak:
And I've seen many agile... I was about to use the word transformation, even though I've just said I don't believe in transformation. Any teams that are adopting agile principles expecting that in their first few sprints they don't have any hiccups, and that if throughput falls in the first few sprints, then there's a bit of a, "Oh, well you told me this thing was going to increase our throughput." Yeah, but not straight away. So I think just being realistic with yourself and what's possible, and that shift in itself, until it normalizes, takes a bit of getting used to. The teams need to know it's a safe environment, that if their productivity suffers, if they make mistakes or if they break things, it's going to be okay. We'll fix forward.
Andrew Malak:
But then also there comes a point in time where we have to be very clear about the culture of accountability around using that capacity really well. So what I've found, that the best use of that is the showcase. And what we've done at Spaceship, because we're trying to reduce the amount of ceremonies, we've combined both the planning playback in a sprint as well as the showcase into the same ceremony. So what we do is we play back what we built last session using a demonstration of working software and comparing the amount of work we've executed versus what was planned in the previous sprint. We're saying we've got 80%, 90% through the work and this is what it looks and feels like, and this is what we're deploying to the customer. Then we actually showcase what we plan to do in the next sprint.
Andrew Malak:
And that's part of the showcase, is our hand on heart commitment to, "This is what we as a team are committed to doing in the next sprint." And then that accountability to the organization becomes something that keeps us on track throughout the sprint. As distractors or things that are not committed in the sprint come our way, we quickly think about, all right, can we accommodate these things? Do they need to be done? Are they going to take us off track with what is planned? Are they important enough? Is it a major defect of production, and can customers no longer access our app? Well, drop what you're doing and attend to that. Otherwise, if it's not material, keep focused on the work that you've committed to in front of the organization.
Andrew Malak:
After this you're going to start to experience some growing pain, and the growing pain is good because it means that agile is working and more teams or more feature opportunities become possible for the business. There's going to be a lot more hype around moving to agile. Other teams are going to come across and say, "Oh, how do we piggyback off what you're doing?" Et cetera. This is good. This is good, but what it means now is that some new risks are going to actually start to be introduced. Working with common code, common dependencies, or even common people being needed to be doing multiple things just means that you now need more coordination. I'd say to anyone who reaches this point in time, this is where people feel compelled to start introducing some new roles, coordination roles. And I'd just say, be careful because that can start add to your overhead really quickly.
Andrew Malak:
I find the best way to ensure that teams continue to be in sync is with the right dialogue at the right level with the right rhythm. And this is where I think keeping it simple to just the scrum of scrums works really well. I like the scrum of scrums to be balanced between both product owner and tech lead from each team being present, and a cadence of one to two times per week works really well. And as long as the product owners across the teams and the tech leads across the teams know what the other teams are working on, know what could impact their own work from a release perspective or scheduling perspective or an environment perspective, I think that tends to work really well as well.
Teagan Harbridge:
Yeah, wow. Lots of nuggets in there and certainly things that resonate with our experience here at Easy Agile, being a small company that's grown really quickly. So I can definitely relate. We've had conversations about, do we introduce new roles into this company? We've introduced a new cadence of meeting rhythms only the last couple of months, so we're going through these things too.
Andrew Malak:
Absolutely. Absolutely. What have been your biggest learnings so far?
Teagan Harbridge:
I think that you cannot underestimate communication, and it really does come back to that cadence and that rhythm with the team. And we're experimenting at the moment with a daily huddle where we're talking about, how do we embed showcases more regularly in our cycles? We've got a big demo at the end of the cycle. How can we make that a more ingrained part of our culture? And it really does come back to that culture of accountability as well. So yep, it's all resonating.
Andrew Malak:
Yeah, absolutely. Look, you can go to whatever industry you want but the problems are usually similar. And the great thing is that having these conversations is very important to fast-tracking your way forward, because your problem is not unique to you. Someone else has seen it in someone else has figured out a way. And I think what I like about the FinTech industry is that we compete on products and services, but there's a lot to learn from each other. And even if you just go outside of FinTech, there's a lot to learn from other industries who have adopted agile practices.
Teagan Harbridge:
If we take a bit of a flip, we've gone from your professional career and your experience into a more personal level. You mentioned that you use agile techniques outside of work. So I'm not sure if many others are in the same boat, but can you elaborate on this? What does that mean? What does that look like?
Andrew Malak:
Okay, I hope you don't think I'm extremely weird. We actually have a family campaign. So I guess if I go back to how we've come to actually doing this. Becoming parents, we would look at our children and see so many things that we want them to be better at. And in trying to give them constant feedback, which felt like the feedback was so much that it's all being drowned out because there's so much of it. In fact, my oldest son actually gave me that feedback. He goes, "Dad, why don't we focus on one thing at a time?"
Andrew Malak:
And I was like, "Wow, okay." For a ten-year-old to tell me that, that was amazing. So we came to realize that we needed to narrow and focus on one improvement area at a time, and we don't move on to the next one until we've actually closed out the first one. For example, my oldest son, very clever boy. We're trying to focus with him on the discipline of process over just getting the answer right, because he is clever and nine times out of 10, ask him a question, he's got the answer and he just wants to say it.
Andrew Malak:
But we've started to try to break down the question and work more on the process with him so that in following the process, coupled with his natural ability, we will get more answers right more often. And that's what we're working through at the moment. So our family's scrum wall at the moment has a mix of things on it. Everyone has their own swim lane, and in each swim lane there are a few tasks, some related work or study, some relating to household chores, some related to health or exercise, and some related to acts of kindness. And what we aim to do is make sure that we're moving things across in all four categories every single day. So yeah, you can use agility wherever you'd like but I think that mindset in general, that if I wake up every day and do things that make me better than I was yesterday, then I'll get to keep moving forward in my personal life as well as my professional life.
Teagan Harbridge:
And do you have WIP limits?
Andrew Malak:
We don't at the moment, and we're not doing showcases at the moment. We'll see how we can introduce them in the future.
Teagan Harbridge:
And how was the introduction of a Kanban board at home? How was that received by the family? Have they enjoyed it, has there been any feedback?
Andrew Malak:
Well, it wasn't actually planned. It started by just sticking some Post-its up on the fridge to remind us of stuff. And then one day I said to my wife, "You know what? This reminds me of what we do at work. Why don't we formalize it?" She had a bit of a chuckle but then one day she came back and then she found it there. So yeah, it wasn't really planned.
Teagan Harbridge:
Awesome. And you've already been super generous with your time so I'll close it out with one final question. What advice do you wish someone would have given you when you took the leap from product management into product leadership?
Andrew Malak:
Yeah, that's a really good question. I think first and foremost, that you've got to make sure that you drop your need for perfectionism, because first and foremost, you might have been the best product manager yourself. You might have been amazing. And I'm not saying I was, but if you were and you step up in leadership role, you're going to have people of different abilities working for you. And what you need to understand is that they're going to need some time learning their role and learning their trade. And just don't get in the way of them learn. So for example, you might see someone doing something that may not be the best or most optimal use of that capacity in that sprint. You might feel the urge to jump in and course correct. But if you let them go and just hear their feedback post the retro, they might've had that learning themselves, and a learning that they get for themselves rather than being told by their leader is going to be much more useful for them.
Andrew Malak:
You have to drop your need to make decisions and be in control because, again, the more you can relegate yourself to a servant leadership role and let the team make decisions, when they make decisions and now have to go back up that decision with execution, they're more likely to put their heart and soul into it. The more they feel like you are going to make the decisions, the less inclined they are to think through problems themselves, and then they'll keep bringing the problems back to you. So every time someone asks you a question that has a black and white answer, throw it back to them and ask them what they think, because that way you're coaching them to work it out themselves. And then the last thing that's really important is, I feel like it's really important to think through how your organization allows you to be different and take advantage of that differentiation.
Andrew Malak:
So for example, at Spaceship here, because we're small, we're not a large corporate, our customers are a little bit more forgiving. So you have a limited capacity to build experiences and you can't do all things at the same time. Understand that and take advantage of it, and get your team to also learn that. Because if you're trying to how the all edge cases, it will take a lot longer to get something to market and you might use a lot of the team's capacity to build edge cases. And you can't really afford that when you're in a start-up.
Andrew Malak:
So for example, we launched a new investment portfolio yesterday. We launched the Spaceship Earth portfolio, our first sustainable investment portfolio and it's a sign of more things to come hopefully in the sustainability space. But in launching that, we knew that we have a limitation in our experience or our product set today where each customer can only have one portfolio. We knew that existing customers would want to invest in sustainable investing, but our commitment to them is that it's in our backlog and it's actually the next feature that we're actually going to take to market.
Andrew Malak:
And in explaining that to our customers, they've been very understanding, that they know our throughput is limited but they also know that their voice is being heard and we are building the things that they're telling us about. So I would say that the best piece of advice to tell my young self is to make sure that you get the balance right between the voice of the customer. That's going to tell you all the hygiene things that your product lacks in terms of experience or gaps. And then get the balance between new strategic things that you can go after and new things that you can take to market, as well as a few Hail Marys every now and again. We call them moonshots. They may or may not work, but it's exciting, and if it works, can 10X your volume. And they are the things that are likely to go viral. So getting the balance right is very important.
Teagan Harbridge:
It's been wonderful, Andrew. I've definitely taken a lot away from our chat today, and I'm sure our audience will too. So thank you again so much for your time, and good luck.
Andrew Malak:
No Teagan, look, thank you very much. And it's been a pleasure speaking to yourself and Easy Agile, and I wish you guys all the best too.
Teagan Harbridge:
Awesome. Thanks Andrew.
Andrew Malak:
Have a good afternoon.
Related Episodes
- Text Link
Easy Agile Podcast Ep.4 Em Campbell-Pretty, CEO & Managing Director at Pretty Agile
"We spoke in detail about scaling agile, being a SAFe fellow, discipline, the traits of effective leaders and how to trust your people."
Transcript
Nick Muldoon:
Good day, folks. Thanks for joining us for another Easy Agile Podcast. This morning, I'm joined by Em Campbell-Pretty of Pretty Agile. Em is one of 22 SAFe fellows globally and she's been doing agile transformations at scale for over a decade now. She's also the author of two books, The Art of Avoiding a Train Wreck and Tribal Unity. So, all about culture and psychological safety here, and all about obviously scaling agile release trains, tips and tricks.
Nick Muldoon:
My key takeaways that I was really jazzed about, the traits of effective leaders for scaling agile transformations and being an effective organization, trust, as in trusting their people, an openness to learning and a willingness to learn, the ability to experiment and treat things as failures if they are failures, and discipline. Em and I talked a bit about discipline today as a trait of leaders. It's a really great episode and I took a lot from it, and you'll hear my takeaways at the end and what I need to go and learn after some time with Em this morning. So, let's get started. How many weeks a year are you typically on the road?
Em Campbell-Pretty:
How many weeks a year am I typically on the road? A lot, most. It would be unusual for me to spend four weeks without going somewhere. That would be unusual. I don't travel every week, but I travel most weeks, and I travel in big blocks. Right? So, I'll go and do ... Like I said, just before the lockdown, we did three weeks in Auckland, so that was in February-March.
Em Campbell-Pretty:
We went to Auckland, we had a client in Auckland, we just stayed there. So, three weeks in Auckland, came back here, and did not return to Auckland. Returned to support that client virtually over Teams and Zoom was how that one went. But yeah. Normally between running around Australia, Southeast Asia, Hong Kong, Singapore, Manila, the US, New Zealand, yeah, not home that often, normally. This has been truly bizarre.
Nick Muldoon:
So, this is a very unusual year for someone like yourself that's flying around visiting clients all over the world.
Em Campbell-Pretty:
Absolutely. Absolutely. It's been a very strange year. It's an interesting difference on energy as well. Not flying all the time I think is good for my body. I feel the difference. I also feel the difference sitting in a chair all the time. So, I was traveling a lot, but I was on my feet most days when I was working. Now if I'm working, I'm sitting a lot.
Nick Muldoon:
You're sitting down. Yeah.
Em Campbell-Pretty:
So, that's interesting. But I don't miss the jet lag at all. I don't miss the amount of time the travel consumes at all. In fact, it's been nice. I've had a little bit of head space. I've probably blogged more this year than I have in a few years because I've just had some head space and being able to think. But I don't get to see the world either, and all my holidays got canceled. So, nevermind work. I had trips to Europe. Four weeks from now, I was supposed to be in Canada seeing polar bears.
Nick Muldoon:
Aw.
Em Campbell-Pretty:
Tell me about it!
Nick Muldoon:
I would love to see polar bears. They look so cuddly on TV. I'm not sure that that would actually be the circumstance if I was to try to approach one and give one a cuddle.
Em Campbell-Pretty:
Yeah. I don't think cuddling was involved. I was told I could bring a camera and a tripod, which means obviously I'm going to stand some distance away from this polar bear and take photos. But that will not be happening either. So, no holidays and no travel for work, and of course, being in Melbourne, not even any, let's just go to [crosstalk 00:04:15].
Nick Muldoon:
Coffee or anything like that.
Em Campbell-Pretty:
Just nothing.
Nick Muldoon:
Nothing.
Em Campbell-Pretty:
Nothing.
Nick Muldoon:
Yeah, because you've been on legit lockdown.
Em Campbell-Pretty:
Yep.
Nick Muldoon:
So, tell me then about the shift over the last 10 or 15 years in these scaled, agile transformations. Obviously today, like you described with this client in Auckland, everything's got to be remote. Presumably, not as effective. But I'd love to get a sense of what the evolution is from the transformations 10 years ago, banking, telcos, that sort of environment to the clients that you're working with today. Describe what it was like 10 years ago.
Em Campbell-Pretty:
So, 10 years ago, and it's so interesting to reflect on this now, I read Scaling Software Agility, which is a book that Dean published in 2007. Then I discovered that wasn't the latest book, so then I read Agile Software Requirements. This was 2011. I'm this crazy, angry business sponsor with this program of work I'd been sponsoring for five years that's never delivered anything, and in this cra-
Nick Muldoon:
You were the crazy, angry business sponsor?
Em Campbell-Pretty:
Yeah. Yeah, yeah. I was the crazy [inaudible 00:05:26]. I was very angry. You would be angry too if you were me. I refer to it now as the money fire. So, basically, here's my job. Right? Go to the CFO, ask for money. Give the money to IT. IT lights a match, sets it on fire. Comes back, asks me for money. I get to go back to the CFO and say I need more money. Five years. Five years. That's all I did. Ask for money and try to explain where the other money went.
Em Campbell-Pretty:
Anyway, in the strangest restructure ever, I end up the technology GM for the same group I had been the business sponsor of for the past five years. Apparently, they couldn't find anybody appropriately qualified. So, you can do it, Em. Sure. So, I'm a bit of a geek, so I read books, and I'm reading these books by Leffingwell because I'd been doing some agile ... So, I'd been doing something I'd been calling agile. Let's just go with that.
Em Campbell-Pretty:
It was interesting to me because I could see little rays of light. But it still wasn't really making anything happen, so hence the reading. These books talk about this agile release train [inaudible 00:06:46] that sounds cool. We should so do this thing. So, I set about launching this train at a Telstra in early 2012. It wasn't called SAFe, right? It was just the books and these things called an agile release train.
Em Campbell-Pretty:
Now, to look back 10 years ago, it wasn't called SAFe. People weren't running around doing this. I was not actually really qualified for the job I was in. Well, I wasn't a technology leader by any stretch of the imagination, and I decide that I'm just going to launch an agile release train. So, there were rare and unusual beasts, and I'm not sure I really understood that when I went down the path of doing it.
Em Campbell-Pretty:
I'm big on the, I read it in a book, I read it in a blog, I heard it at a conference, I'll just try it. That's very much always been my mental model. So, I read it in a book and I just tried it. Then we discover that actually, literally nobody is doing this, so it becomes Australia's first agile release train and Australia's first SAFe implementation. Oh, boy, have I learned a lot since then.
Nick Muldoon:
Well, yeah. I was reflecting on that because I dug out The Art of Avoiding a Train Wreck, right? This is one of the ones that you signed for Tegan. But obviously, you've learned a ton since then because you've managed to put together a tome of tips and tricks and things to avoid as you are pursuing these transformations. As an industry, though, well, as an industry, I guess this spans many industries, but as a practice these days, are we actually getting better at these transformations? Are there companies out there today, Em, that are still taking piles of money and setting it on fire?
Em Campbell-Pretty:
So, I think I meet people every day who hear my story and go, "Oh, my god. You used to work here?" So, I think there's still many, many organizations that have an experience that is like the experience I had back in 2010 and what have you. So, it seems to be something that really resonates with people. I guess so many of the businesses we go into now either are not agile at all or, I guess like my world was, doing something they call agile. What we find is the something that they call agile, I wouldn't say it's not agile. But it leaves a lot to be desired.
Nick Muldoon:
They're on a journey, right?
Em Campbell-Pretty:
Yeah. Yeah. Well, I guess so because they end up having a conversation with us. So, they understand that what they're doing is not enough. They understand that what they're doing isn't getting them the results that they want. I don't know that they understand why. It's interesting to me sometimes that they look to SAFe because you asked me about how's the client base changed? One of the things that's really interesting in Australia is we get far more of the small to medium sized companies now than the big ones.
Em Campbell-Pretty:
So, they're companies that consider themselves agile. But what we're calling them, the startups that are no longer startups, right? These are organizations that they're generally old 10, 20 year old startups and they're scaling and they see their problem as a scaling problem. So, that's what leads them to a conversation around the scaled agile framework.
Em Campbell-Pretty:
When we look at them through a SAFe lens, we go, "Gee, you're tiny. But okay. I can see that you can have an agile release train and it won't do you any harm. In fact, it would probably help you a lot in terms of mid-range planning," because mid-range planning just seems to be nonexistent for a lot of these organizations. Prioritization. A lot of these small organizations, very knee-jerky in terms of how they prioritize, bouncing from one thing to the other.
Nick Muldoon:
Are they reacting to the market, or are they reacting to the leaders, maybe the lack of discipline in the leadership?
Em Campbell-Pretty:
You know what? They would say they're reacting to the market. I would say they've got a discipline issue.
Nick Muldoon:
Yeah. [crosstalk 00:11:23].
Em Campbell-Pretty:
So, I read, obviously, big reader, last summer, obviously Australian summer, US winter, I read Melissa Perry's The Build Trap. Interesting book and your well respected thought leader in product management. Not a big fan of SAFe. Probably not a big fan of agile either was the takeaway I had from her book. But the thing that she does talk about that I really thought was valuable was the lunacy in chasing your competitors. So, building features because your competitors-
Nick Muldoon:
Your competitors [crosstalk 00:12:06].
Em Campbell-Pretty:
... build them, or building features to land a contract or retain a customer. So, I thought she sees all of that as lunacy, and I tend to agree. So, that was my ... I think that's quite interesting. Her perspective is you don't know if the competitor's actually having any luck with that thing that they've built. So, if you build it because they built it, you don't know. You have no idea. So, don't just build it because they've built it. It might not be doing them any favors either.
Em Campbell-Pretty:
Of course, once you start just doing random stuff for this big customer or this big client, you start to lose your way as an organization. People end up with completely different versions of their products, branches that they can't integrate anymore. It's interesting. So, when I look at that, I go, "I feel like there's a discipline issue in some of these organizations at the leadership level."
Em Campbell-Pretty:
What is it we're trying to do? What is our vision? What is our mission? What is our market? What are we doing to test and learn in that market, as opposed to just get a gun, let's do everything, grab everything? Oh, my goodness. They were doing that over there. Stop this, start this, stop this. Of course, if you're stopping and starting all the time, you're not delivering anything, and that seems to be something that we see a lot with these organizations. They're not delivering.
Em Campbell-Pretty:
I'm not saying their delivery mechanism is perfect. There's challenges there too. But some part of the problem is the inability to stay a course. Pick a course and stay a course. I'm not saying don't pivot, because that's stupid too. But being more deliberate in your choices to pivot, perhaps. Yeah.
Nick Muldoon:
Do you get a sense, Em, that there are leadership teams in various geographic regions that are more effective at this and more effective at that longterm planning and having that discipline and that methodical approach to delivery over an extended time period?
Em Campbell-Pretty:
I think regions and cultures and nationalities certainly play a role in the leadership, I don't know, persona, personality. I don't know that I could say when I've worked in this country or this part of the world that their leaders are better at forethought. I think some cultures lend themselves to lean and agile more than others. Hierarchical cultures are really, really challenging.
Em Campbell-Pretty:
That can be both a geographic thing, but it can also just be an industry thing, right? So, government can be very hierarchical. The banks can be very hierarchical. Some of the Asian cultures are very hierarchical. But some companies are just very hierarchical as well. So, who owns the company, who leads the company, all of that can play a big role in what's acceptable because so much of success in this scaled agile journey comes down to a leadership that is willing to trust the teams, a leadership that is willing to learn, a leadership that's willing to experiment, and a leadership that's prepared to be disciplined.
Nick Muldoon:
So, leadership with trusting the teams, willing to learn, willing to experiment, and with discipline. They're those four things that you-
Em Campbell-Pretty:
Yep.
Nick Muldoon:
Yeah, okay. I'll make a note of those, Em. I'll come back to those. Trust, learn, experiment, and discipline. I'm interested, I guess, this year being a very interesting, a very unique year for doing remote transformation work and coaching and consulting, 10 years ago, what was the percentage of remote team members distributed teams? Now, you've basically, I think the big banks in Australia aren't even going back to the office until 2021. Atlassian is not going back to the office until 2021. Twitter, Jack Dorsey, my old CEO, said, "Work from home forever," sort of thing. What's the takeaway for this year and what do you expect for 2021 and beyond?
Em Campbell-Pretty:
So, look. This year has been eyeopening, and look, some things are, as I would have anticipated, some things have been different. So, obviously, we're seeing entire organizations going online. We're seeing the teams are online, the PI planning's online, everything's online. That's actually in some ways opened up opportunity. So, where we've had clients who have had the most odd setups in terms of distribution, and you can make a train work where you've got teams across two locations. But we're big fans of the entire team is in Sydney or the entire team is in India. We don't have half the team in Sydney and half the team in India.
Em Campbell-Pretty:
But organizations really struggle with that because perhaps all the testers are in India and then you want a tester on every team and now you've got a problem. How do you create a complete team and not cross the time zones? So, the opportunity becomes if I can find teams that are not physically co-located but time zone friendly, I have a little bit more option. So, I can have a train that operates between, I don't know, Sydney and India. Or I can find a four hour overlap in their day, and I can insist that that team works 100% online.
Em Campbell-Pretty:
So, the big thing that we'd advise against is I don't want that team hybrid. Right? I don't want three people sitting in the office in Sydney and three people sitting in their homes in India. I want everybody online. I want an even playing field, and I think we can do that now in a way that is more acceptable than before. Because the same advice I was giving, gee, back when I wrote Tribal Unity, same advice. Right?
Em Campbell-Pretty:
So, 2016, everybody, equal playing field. If you're going to be distributed, everyone has to be online, as opposed to some people online and some people in a room. So, that's a more acceptable answer now than it was prior to this year. So, that's good. I think that's good.
Nick Muldoon:
In 2021, then, Em, you mean this is just going to play forward. I guess there's going to be a reversion of some of these companies back to the office because they've got huge real estate and workplace infrastructure already.
Em Campbell-Pretty:
Yeah. So, look. We're seeing clients closing offices the same way that you see some of the companies in the US doing that. We're also seeing parts of Australia and New Zealand with no particular COVID impact at this point actually going back into the office, and having created that example of teams that are crossing time zones, and then going back into the office and going back to that hybrid space. So, that's interesting and [crosstalk 00:20:08].
Nick Muldoon:
So, where you're back into that environment where you might have some people working together in an office that can get a cup of coffee together and then some that are stuck still at home. I guess there's not just even regional differences, right? If you've got a team member that's got a particular health situation, they're not going to feel comfortable necessarily coming back into the office, regardless of the situation, until there's a vaccine or something.
Em Campbell-Pretty:
Absolutely.
Nick Muldoon:
Yeah, okay.
Em Campbell-Pretty:
So, yeah. Look, I think it's going to be interesting. I would strongly advocate that organizations have teams that are either in person teams or online teams, and the team just either operates 100% online or the team operates 100%-
Nick Muldoon:
In the office.
Em Campbell-Pretty:
... in person and in the office, and if you have a train that has both in any train level ceremony, everybody goes to a desk and-
Nick Muldoon:
And do it online.
Em Campbell-Pretty:
... a video camera and we do it that way. I think the thing that seems to be most sticky about the physical environment and SAFe is PI planning. Nobody needs to beat. Right? That was cool. Nobody needs to beat, no one's PI planning slipped, everybody just went. They were all online. So, we'll just PI plan online. It'll be fine. We saw people use whatever infrastructure they had available to them.
Nick Muldoon:
Yeah. [crosstalk 00:21:30].
Em Campbell-Pretty:
So, I'm sure a number of people called you folks and said, "We need a tool." But some just went, "We have Google Suite, we have Microsoft whatever it is, we have this, we have that. We're just going to make it work," and no matter what they used, they made it work and they ran the events and their events were effective and they got the outcomes. The big thing that is missing is that energy. You can't get the energy of 100, 200 people in a room from an online event. But mechanically-
Nick Muldoon:
We can achieve it.
Em Campbell-Pretty:
... we can achieve it. So, we hear everybody wants to go back to PI planning in person because of the social, because of the energy, which I think is awesome. I absolutely think that is awesome, and I can see this world in which people do a lot more work from home, work remote, whatever that looks like, and then the PI planning events are the things that we do to bring ourselves together and reconnect on that eight, 10, 12 week basis. That's my feeling. Could be wrong.
Nick Muldoon:
I guess I'll be really interested to see how it plays out, and I think we should return to this conversation in 12 months, Em.
Em Campbell-Pretty:
Yeah. Oh, no.
Nick Muldoon:
I'm just thinking, what's going through my mind is one of our customers in New York, financial services company, and for one of their arts, it was 150,000 US exercised to bring their people together once a quarter.
Em Campbell-Pretty:
Yeah. Wow.
Nick Muldoon:
I'm now going, I'm like, "Okay, yes, they're doing it digitally now." That's fine. They're going to miss out on things. But if they lose the budget, do they have to fight to get the budget back? Or does the budget sit there? There's these other unknown ramifications of this shift over the course of 2020 that we're yet to see play out, I guess.
Em Campbell-Pretty:
I think you're right, and I think it would be particularly interesting for the trains that have been launched remotely. So, if the train has been launched remotely, do you ev-
Nick Muldoon:
So, not existing trains that have been working together for six to 12, 18 months. But you want to get a brand new train started. Have you done that remotely this year with some of your clients?
Em Campbell-Pretty:
Oh, we're in the process of doing it now.
Nick Muldoon:
Cool. Tell me.
Em Campbell-Pretty:
We had one, though, literally just before the lockdown. So, they did their first PI planning face to face and then immediately moved to remote working and, yeah, now working on remotely launching a train. For us, we have a playbook. It's a bunch of workshops. It's a bunch of classes. We just use online collaboration tools. We've found things that replicate the sort of tools that we would have in a physical room, and the joy of being able to read people's Post-it notes, right? This has been the absolute highlight for me, the joy of being able to read people's Post-it notes.
Nick Muldoon:
No more hieroglyphics.
Em Campbell-Pretty:
Yeah. Absolutely.
Nick Muldoon:
What is that that you wrote, Sally? Yeah.
Em Campbell-Pretty:
Everyone can say everything at once, right? So, you think about the classroom and the workshop where there's a group of people huddled around Post-its and a flip chart paper and they're still huddled in a way in their virtual huddle, but everybody can read, right? It's not that I'm not close enough, I can't read, I can't read your handwriting. There's this great equalizer is the online world. So, I think that's great. I think the challenge for the trains launched remotely is going to be do you ever get the face to face experience?
Em Campbell-Pretty:
Because if I go back over the years, one of the things we know is your first PI planning event sets the standard. So, people get this imprint in their heads of what is possible. For example, if you skip something in your first PI planning event, you just decide to, I don't know, skip the confidence vote or something weird like that, you don't do the roam of the risks or you just skip something, you never do it because you're successful without it.
Nick Muldoon:
It never gets picked up. Yeah, okay.
Em Campbell-Pretty:
You're successful without it. So, every compromise you make, and you make a series of compromises, and then you're successful despite those compromises, and that becomes a false positive feasibility. It tells you, yes, I was right. I was right.
Nick Muldoon:
I don't need to do that.
Em Campbell-Pretty:
I didn't need to do those things because I was awesomely successful and I didn't do these things. So, it's the learning [crosstalk 00:26:15]-
Nick Muldoon:
That's confirmation bias, is it?
Em Campbell-Pretty:
Yeah, that's it. That's the one. Confirmation bias. That's exactly it. Yep. Yeah, and I think there's going to be a bunch of confirmation bias in these remotely launched trains, and unless they're inside organizations where there's enough knowledge of SAFe and the physical PI planning to know that there's going to be value in bringing them together, but I can see that being a real challenge. I think trains that are launched online may never go into a physical PI planning event because of that confirmation bias.
Nick Muldoon:
All right.
Em Campbell-Pretty:
That makes me really sad.
Nick Muldoon:
I want to come back to something you said before about the leaders, and you mentioned the trust, the openness to learning and experimentation, and the discipline. I was going back over your SAFe Global 2018 talk about the seven traits of highly effective servant leaders.
Em Campbell-Pretty:
Yep.
Nick Muldoon:
Yeah?
Em Campbell-Pretty:
Yep.
Nick Muldoon:
I guess I had some questions about this, and obviously, these are four of the traits. What are the other three traits that I'm missing? Then I've got a followup question about some of the actual things that you talked about that you picked up in your trip.
Em Campbell-Pretty:
[inaudible 00:27:29] one of those four on the list I had in 2018.
Nick Muldoon:
I'll quiz you on it.
Em Campbell-Pretty:
How awkward. So, in 2018, the answer was people first, a respect for people, that sort of lens, lean thinking, manager, teacher, learner. So, we had that one. Yeah. Learner. [inaudible 00:28:00] crazy. What else did I have? [inaudible 00:28:10].
Nick Muldoon:
Yeah. Okay. I wanted to talk about that one, actually. I made a note about that. What is that, and are there examples of that in the West?
Em Campbell-Pretty:
A lot of people talk about true north.
Nick Muldoon:
[inaudible 00:28:28]. True north.
Em Campbell-Pretty:
Yeah. True north. The translation I got, which I got from Mr. [inaudible 00:28:39], who partnered with Katie Anderson for the lean study tour I did in, I don't know, '18, '17, '18, 2018, I think, so the translation he gave was direction and management sort of things. So, it's mission, right? It's strategic mission. It's that sort of thing.
Nick Muldoon:
So, just a sidebar here for anyone that hasn't seen Em's talk on this, there's a woman by the name of Katie Anderson. She runs an annual, I think, I guess not this year, but she runs an annual-
Em Campbell-Pretty:
No, not this year. She did not go this year.
Nick Muldoon:
... not this year, runs an annual lean, Kanban, kaizen study tour to Japan and visits ... Who did you visit, Em? You visited with Katie. How many were in the crew that you went over there with?
Em Campbell-Pretty:
So, I think it was a group of about 20 from memory. Katie lived in Japan for two years and then went back to the US. She lives in San Francisco, I think. While she was there, she really liked the idea of putting together these lean study tours. She was already a lean practitioner more in the healthcare side of things. So, she got the opportunity to ... We actually were on a test run tour.
Nick Muldoon:
Oh, cool.
Em Campbell-Pretty:
So, this was her experiment. She had a relationship with Ohio State University and they brought some people to the table and she brought some people to the table and they made it happen. She also had an existing relationship with Mr. [inaudible 00:30:24], who was John [inaudible 00:30:26] first manager at Toyota. So, he's a 40 year Toyota veteran.
Nick Muldoon:
Veteran.
Em Campbell-Pretty:
He came with us for the week. So, we of course went to Toyota, but we went to a bunch of Toyota suppliers as well. Isuzu, [inaudible 00:30:43]. Then we also went to Japan Post, which was fascinating. We went to a city which name escapes me right now, but they called it 5S City because all the companies in that city practice the 5S, the manufacturing 5S.
Nick Muldoon:
Tell me about it. It's not coming to mind. I don't feel comfortable or familiar.
Em Campbell-Pretty:
You don't feel good about 5S?
Nick Muldoon:
No.
Em Campbell-Pretty:
No. That's not good. So, how would I ... The 5S is five Japanese words, which I'm going to go ... Yeah. My Japanese, nothing. But it's about standardized work. So, for example, when you go into the 5S factories, you'll see the floors marked up where you need to stand to do a particular job.
Nick Muldoon:
[crosstalk 00:31:41] This is what Paul Aikas picked up for his-
Em Campbell-Pretty:
Oh, no.
Nick Muldoon:
I feel like I've seen Paul Aikas' videos of their manufacturing in the US that everything's marked up.
Em Campbell-Pretty:
Yeah.
Nick Muldoon:
Okay.
Em Campbell-Pretty:
Probably. That would be my guess. We should ask Teddy.
Nick Muldoon:
We can ask Paul, and we can ask all these people. There's time.
Em Campbell-Pretty:
Well, yeah.
Nick Muldoon:
Okay.
Em Campbell-Pretty:
Okay.
Nick Muldoon:
So, that lean tour, the Japan study tour, that was a super effective and motivating thing for you?
Em Campbell-Pretty:
Yeah. For me, it was very reinforcing. So, I had I guess my own lens on what lean leadership meant, and I found that particular tour to be very reinforcing around the value set that I believe is part of that. Katie [inaudible 00:32:43] created [inaudible 00:32:44] that is designed to show you that. So, she's often very clear that says this is not Japan, right? This is not a reorganization into Japan. This is not every leader in Japan.
Em Campbell-Pretty:
This is, I've hand picked a series of lean leaders to show you it being practiced. But it was certainly very reinforcing for me. So, very similar messages I picked up in terms of how I like to head, how I coach others to lead was built into the messages that she delivered. So, it was very cool. It was very cool. Some of those leaders, just so inspiring, particular kaizen. I think the thing that just really hits you in the face as you're talking to these folks is kaizen, this drive to get better.
Nick Muldoon:
All the time.
Em Campbell-Pretty:
All the time. Absolutely. It's these folks looking for, they're looking for the one second, right?
Nick Muldoon:
Yeah.
Em Campbell-Pretty:
The one second improvements. There's a video that floats around. Have you seen the Formula 1 video-
Nick Muldoon:
Yeah.
Em Campbell-Pretty:
... where they do, yeah, the changeover in 63 and it takes them over a minute and they do the changeover in 90-something in Melbourne and it takes them six seconds or whatever it is. It's like that, right? It's that how do I find one more second, half a second? They're just so driven. If I can remove a step that someone has to take, can I move something closer to somebody?
Nick Muldoon:
Yeah. There was some comment in the presentation that you gave. There was some comment about if I have to take another five steps, that's an extra 10 seconds. Then that's an extra 10 seconds every time I do this activity every day, and that all adds up. So, how do we shave these seconds off and be more effective and deliberate about how we do this?
Em Campbell-Pretty:
That was just huge, right? I called it kaizen crazy in the presentation. I'm just so, so driven to improve, and just tiny, small improvements every day.
Nick Muldoon:
So, one of the other practices that I didn't grok out of that talk was about the Bus Stop. What was the Bus Stop about?
Em Campbell-Pretty:
Was that in that talk? Really?
Nick Muldoon:
I'm forcing you to stretch your mind [crosstalk 00:34:57].
Em Campbell-Pretty:
You are. You are. You are. You are quite right. It really was [inaudible 00:35:01]. Okay. Oh, you're awful.
Nick Muldoon:
Yes.
Em Campbell-Pretty:
Yes. Yes, you are. Okay. So, effective leaders are human was the tagline on that one. It was really about leaders being down to Earth and being one with the teams. So, things I saw in Japan, this factory run by a woman, [inaudible 00:35:42], I think it was, so very unusual. Not a lot of women leaders in Japan. Her husband took her name because [inaudible 00:35:52]. It's a really interesting character.
Em Campbell-Pretty:
But her company has a bunch of morning rituals. You always say good morning and thank you and how they talk every day and everybody talks and everyone interacts. Then one of the other places we went to, they all had their uniforms they wore in the factory. But everybody wore the uniform, right? The CEO, the office workers, and everybody wore the uniform. Everyone was one.
Em Campbell-Pretty:
Then I was thinking about my experience leading teams, and a lifetime ago, I was working with a team that decided to enter a corporate competition. This competition was about showing your colors and showing the corporate values, which were things like better together and courage, and then [inaudible 00:36:49] a rainbow thing. So, this team decides what they're going to do, is it an address up in the rainbow colors, and they're going to be better together and show their courage and they're going to do the Macarena and they're going to video it and that's going to be how they're going to win this competition.
Em Campbell-Pretty:
I did not participate in this Macarena because someone has to take photos and stuff, right? How else are they going to enter the competition? So, had to do my bit. Anyway, we also had this ritual, which was about teams bringing challenges to leadership to resolve, and they did at the end of every spring. So, they do this Macarena and they film it and they enter the competition and at the end of the spring, they bring their challenges to leadership.
Em Campbell-Pretty:
Their challenge is Em did not do the Macarena. You are our leader, you did not do the Macarena. We are feeling very challenged by that, and we're bringing this to you to resolve. So, I went and spoke to the team that raised and said, "Look. I got to tell you. I don't know the Macarena. So, sorry." I still remember this so clearly. One of the guys said to me, "I read this blog about the importance of leaders being vulnerable." You know who wrote that blog post, don't you?
Nick Muldoon:
Oh, Em. Oh. You have it.
Em Campbell-Pretty:
So, we negotiated. I said, "Look. I think I can manage the Bus Stop." For those not from Australia, we grow up doing this in high school dances. In my part of the world, anyway. So, I grabbed my leadership team and we did do the Bus Stop and it was part of proving that we too were the same as everybody else and doing our bit and responding to the team's feedback. So, yes. That is where the Bus Stop fits in. Thanks so much for that, Nick.
Nick Muldoon:
Okay. No, I appreciate that. Now, I'm glad that I got that context. I try and do similar things. Typically, it's a karaoke or something, or that we haven't done that in a while. Yeah, okay. So, I guess the thrust of that talk was really about to leaders to serve, and it was all about being in service of. It sounds like what you took from the Japan study tour was these leaders there were very much in service of their people.
Em Campbell-Pretty:
Absolutely.
Nick Muldoon:
Do you see that as a trait that is prevalent in the best performing companies that you deal with, and how likely are they over a five, 10 year horizon, whatever that happens to be, to outperform their competitors or to be more successful in their market? Or I guess however they define success?
Em Campbell-Pretty:
I certainly see a correlation between leaders that like to serve and/or choose to serve and success with scaled agile, and business, because I guess we have seen over, it's close to 10 years, is those who practice together, your framework with discipline get results, and they get significant results. They improve their ability to deliver products and services, their cost base goes down, their quality goes up, their people are happier, their attrition goes down. We see it every single time.
Em Campbell-Pretty:
What we also see is when the leaders don't walk the talk, when the leaders are paying lip service to the transformation, it doesn't stick. They don't get the results. People don't find it a better place to work. People aren't bought into the change. So, there is definitely a correlation there. You can get pockets of wonderfulness inside an organization.
Em Campbell-Pretty:
We often observe that the organization that's transformation is as successful is the most bought in leader. Most senior bought in leader. So, if you're the leader of a train and you show the right behaviors, your train will be really great.
Nick Muldoon:
Successful.
Em Campbell-Pretty:
But that means nothing for the broader organization, solution train, the business unit, what have you. You see this thing that goes from the leader. If the leader's showing the right behaviors, you get within that space, you get the behaviors, you get the change, you get the results. But leaders who say one thing and do another, people don't buy it, right?
Nick Muldoon:
I guess this is true of any organizational change, isn't it?
Em Campbell-Pretty:
Yeah.
Nick Muldoon:
You hit the boundaries of your pocket, as you said, within the organization and then you meet the real world, the rest of the organization. People, maybe they don't have enough energy or they don't feel that they can influence and change that, and so they just live within their bubble because they don't feel that they can exert the pressure outside of that.
Em Campbell-Pretty:
Yeah. Look. I've certainly, I've seen successful bubble influence organizations. Successful bubbles can become interesting. Chip and Dan Heath's book, which one was it, Switch.
Nick Muldoon:
Oh, yeah. Switch. Yeah.
Em Campbell-Pretty:
[inaudible 00:42:02]. Shine a light on bright spot or something like that. So, bright spots inspire, and if you can create a bubble in an organization that outperforms the rest of the organization, or even if it performs better than it has previously, then everybody looks. Right? How did the organization that goes from poor delivery to great deliveries is what is going on here? That inspires others to get interested. One of the really interesting things we've seen in Australia, we can trace pretty much every SAFe implementation in Australia back to the one at Telstra.
Nick Muldoon:
Yeah, right. They all spun off from that, from the people that were part of it.
Em Campbell-Pretty:
Well, no. People who came and saw it. People who were inspired by it.
Nick Muldoon:
They're not necessarily directly involved in it.
Em Campbell-Pretty:
No. People came and got inspired by it, and then they went, did their thing, and then they inspired someone else. I haven't tried to do it recently, but there was a point in time we just could web together all of them because we could count them when we could see them. But we can web together most of them still. It says you saw someone who saw someone who saw someone who actually was someone who went to visit us at Telstra back in 2012, 2013 and got inspired.
Em Campbell-Pretty:
So, that bright spot can be really, really powerful, and that's what it takes, right? You get to add a little bit of noise, a little bit of difference, and people start to ask what's going on. I wouldn't say it's foolproof. I think it still requires, so someone's got to come, they've got to see, and then they've got to have the courage to do it for their part of the organization.
Em Campbell-Pretty:
That's the hard bit, right? I can come, I can see, I can get inspired. But am I prepared to put myself out there? There's a lot to be said for leaders who are prepared to take risks. That was one of the-
Nick Muldoon:
This was your lesson about the Bus Stop, right? You have to put yourself out there and be vulnerable.
Em Campbell-Pretty:
Yeah. Absolutely. Absolutely. This was actually, I was thinking, was the thing I was talking about at last year's SAFe Summit was be safe or be SAFe.
Nick Muldoon:
Be safe or be SAFe. Tell me about that.
Em Campbell-Pretty:
So, be safe, don't take a risk, or be SAFe, as in the scaled agile framework, and take that leap of faith. It comes back to, we started talking today about when I did this at Telstra, I didn't really understand that this wasn't a normal everyday, this is what everybody did sort of thing. It was a very new thing. So, I took a risk from a perspective that I was a business leader in a technology space and I really felt I had nothing to lose.
Em Campbell-Pretty:
So, I look back and that and go, "What on Earth possessed me?" And I go, "Well, I'm this business person leading this technology team. I wasn't supposed to succeed anyway."
Nick Muldoon:
Put it all on the line, right?
Em Campbell-Pretty:
I found out later they actually had a plan for when I did not succeed. I was supposed to fail.
Nick Muldoon:
Wait. How much waste is that? Why did they plan for something before it was ... Okay.
Em Campbell-Pretty:
Organizational policies. What can I tell you? Anyway, I did not fail. I did succeed, and because I took some crazy, calculated risks, and I've seen it time and time again, right? So many of these leaders in these companies that make this change are taking a leap of faith. I'm always saying I can't tell you exactly what's going to happen. I don't know whether you're going to get 10% cost out or 50% cost out. I don't know if your people are going to be 10% happier or 50% happier. I don't know that.
Em Campbell-Pretty:
What I do know is if you listen to what we're telling you and you follow the guidance and you behave in line with those lean and agile values, you will get results. You'll get results every single time. But you've got to be brave enough to buy in and take it on holistically and not do this thing where you manage to customize your way out of actually doing the thing-
Nick Muldoon:
Doing anything.
Em Campbell-Pretty:
... that you wanted to do.
Nick Muldoon:
Yeah. Okay. Em, this was awesome. Before we finish up, I want to take two minutes. You've mentioned books a lot today and you reminded me of this quote, Verne Harnish, "Those who read and don't are only marginally better off than those who can't." So, today so far, you've mentioned Chip and Dan Heath with Switch, you've mentioned the Leffingwell series from the late noughties. There might have been a few others. But tell me, what are you reading today? You've been in lockdown. What are the two or three top books that you've read since you've been in lockdown in Melbourne?
Em Campbell-Pretty:
Oh, my goodness. It's very awkward. Every time someone asks me, "What did you just read?" I go, "I don't know."
Nick Muldoon:
I don't think I remember.
Em Campbell-Pretty:
Can't remember. It's terrible. What am I reading? I need to open my Kindle. I don't know what I'm reading. Geoffrey Moore, Zone to Win.
Nick Muldoon:
Zone to Win.
Em Campbell-Pretty:
Zone to Win. I think that's what it's called. It's a newer book. I know this year, because obviously, I've read The Build Trap this year-
Nick Muldoon:
Yep. Melissa Perry. You mentioned that one. Yeah.
Em Campbell-Pretty:
Yep. I've read the Project to Product, Mik Kersten.
Nick Muldoon:
What was that one, Project to Product?
Em Campbell-Pretty:
Yeah. Project to Product, Mik Kersten. One of the IT Revolution press books. So, released just over a year ago. Very tied up in the SAFe 5.0 [crosstalk 00:48:21]. The other book tied up in the SAFe 5.0 release is John Kotter's Accelerate. So, I picked that back up. I read it a number of years ago when it first came out. But I like to revisit stuff when SAFe puts it front and center. Seems to make some sense to do that at that point in time.
Nick Muldoon:
Yeah, okay. It's interesting that, thinking about Verne Harnish, the scaling up framework, no relation to-
Em Campbell-Pretty:
No.
Nick Muldoon:
... scaled agile, for anyone that's not familiar. But so much of the scaling up framework about scaling businesses, they draw on so much content from existing offers, existing tomes, points of reference and experience, and it's super valuable, and I guess SAFe is no different, right? It draws on this wisdom of the collective wisdom.
Em Campbell-Pretty:
Absolutely. Absolutely. [inaudible 00:49:14] It was very fun to say in the early days, we stand on the shoulders of giants, a quote from somebody else whose name escapes me.
Nick Muldoon:
Yeah, okay. Well, Em, look. I wanted to thank you so much for your time this morning. This has been fantastic.
Em Campbell-Pretty:
No worries. It's great to catch up with you.
Nick Muldoon:
Yeah. I guess my takeaways from this, I like the be safe or be SAFe, like either be safe and don't take any risks, or be SAFe and actually put yourself out there and step into scaled agile. I definitely have to go and do a bit of research on the five S's as well and learn a bit more about that. But thank you so much for your time. I really appreciate it.
Em Campbell-Pretty:
No worries, Nick. Great to see you.
- Text Link
Easy Agile Podcast Ep.25 The Agile Manifesto with Jon Kern
"Thoroughly enjoyed my conversation with Jon, he shared some great perspectives on the impact of the Agile manifesto" - Amaar Iftikhar
Amaar Iftikhar, Product Manager at Easy Agile is joined by Jon Kern, Co-author of the Agile Manifesto for Software Development and a senior transformation consultant at Adaptavist.
Amaar and Jon took some time to speak about the Agile Manifesto. Covering everything from the early days, ideation, process, and first reactions, right through to what it means for the world of agile working today.
They touch on the ideal state of an agile team, and what the manifesto means for distributed, hybrid and co-located teams.
We hope you enjoy the episode!
Transcript
Amaar Iftikhar:
Hi everyone. Welcome to the Easy Agile Podcast. My name is Amaar Iftikhar. I'm a product manager here at Easy Agile. And before we begin, Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast today, the people of the Dharawal speaking country. We pay our respects to elders past, present, and emerging. And extend that same respect to all Aboriginal, Torres Strait Islander, and First Nations peoples joining us today.
Today, we have on the podcast Jon Kern, who is the co-author of the Agile Manifesto for Software Development and an Agile consultant. If you're wondering, you're correct. I did mention the Agile Manifesto for Software Development. The Agile Manifesto. So Jon, welcome for being here and thank you for joining us.
Jon Kern:
Oh, my pleasure, Amaar. Thank you.
Amaar Iftikhar:
Yeah, very excited to have you on. Let's just get started with the absolute basic. Tell the audience about, what is the Agile manifesto?
Jon Kern:
Well, it's something that if you weren't around, and I know you're young, so you weren't around 21 years ago, I guess now, to maybe understand the landscape of what software development process and tooling and what most of us were facing back then, it might seem like a really obvious set of really simple values. Who could think that there's anything wrong with what we put into the manifesto? But back in the day, there were, what I practiced under as a... I'm an aerospace engineer, so I was in defense department work doing things like fighter simulation, F-14 flat spins and working with a centrifuge and cool stuff like that. And subject to a mill standard specification, which makes sense for probably weapons systems, and aircraft manufacturing, and all sorts of other things. But they had one, lo and behold, for software development. And so there was a very large, what I would call heavy handedness around software development process. We call it heavyweight process. Waterfall was the common term back then, and probably still used today.
And there were plenty of, I would say the marketing juggernaut of the day, IBM and Rational unified process, these large, very much like Safe. Where it's a really large body of work, awesome amount of information in it, but very heavy process even though everything would, say you tailor it, it could be whatever you wanted. I mapped my own lightweight process into REP for example. Sure. But the reality was we were facing kind of the marketplace leader being heavyweight process that was just soul crushing, and from my perspective, wasting taxpayers' money. That was kind of my angle was, well, I'm a taxpayer, I'm not going to just do this stupid process for process sake. That has to have some value, has to be pragmatic. So lo and behold, there were a handful of us, 17 that ended up there, but there are a handful of us that practiced more lightweight methods. So the manifesto was really an opportunity for coming together and discovering some of the, what you might think of as the commonality between many different lightweight practices. There was the XP contingent. I first learned about Scrum there, for example. Arie van Bennekum, a good friend, he taught us about DSDM. I don't even remember what it stands for anymore. It was a European thing.
Alistair and Jim Highsmith, they had, I forget, like crystal methodologies. So there was a fair amount of other processes that did not have the marketing arm that erupted, or didn't have the mill standard. So it was really all about what could we find amongst ourselves that was some sort of common theme about all these lightweight processes. So it was all about discovering that, really.
Amaar Iftikhar:
You all get together, the principles kind of come to fruition, and let's fast forward a little bit. What was the initial reaction to the original manifesto?
Jon Kern:
Yeah, it was even kind of funny that the four values, the four bullets is as simple as it was. The principles came a bit later. I want to say we collaborated over awards wiki, but the original... If you go to Agile uprising, you can see I uploaded some artifacts, because apparently I'm a pack rat. And I had the original documents that Alistair probably printed out, because he was the one... He and Jim lived there near Salt Lake City. So it was like, "Hey, let's come here." And we like to go skiing, so let's do it here. So he arranged the room and everything. And so there's some funny artifacts that you can find. And the way that it actually came about was an initial introduction of each of us about our methods. And really I think a key, we left our egos at the door. I mean I was a younger one. Uncle Bob, some of these, he was at Luminar, I know I have magazines still in the barn that he was either the editor of, or authors of for people who don't remember what magazines are. Small little booklets that came out. So Uncle Bob was like, Ooh, wow, this is pretty cool.
And I wasn't shy because I had a lot of experience with heavyweight methods. So I really wanted to weigh in on... Because I had published my own lightweight method a few years earlier. So I had a lot of opinions on how to avoid the challenges of big heavyweight process. So the culmination as we were going out the door and after we had come up with the four values was I think Ward said, "Sir, want me to put this on the web?" And again, this is 2001 so dot com and the web's still kind of new so to speak. And we're all like, yeah, sure, why not? What the hell, can't hurt. We got something, might as well publish it. I don't think to a person, anybody said, "Oh yeah, this is going to set the world on fire because we're so awesome." And we were going to anoint the world with all of this wonderful wisdom. So I don't think anybody was thinking that that much would happen.
Amaar Iftikhar:
Yeah. So what were you thinking at that time? So how would the principles that you had come up with together, was that maybe just for the team to take away? Everyone who was there? What was the plan at that time?
Jon Kern:
I think it was a common practice. Like I said, there were other groups that would often meet and have little consortiums or little gatherings and then publish something. So I think it was just, oh yeah, that's a normal thing to do is you spent some time together and you wrote things down, you might as well publish it. So I think it wasn't any deeper than that other than Bob, I think Bob might say that he wanted to come up with some kind of a manifesto of sorts or some kind of a document because that's I think what those sort of... I was never at one of those gatherings, but you know, you could see that they did publish things. I have a feeling it was just something as innocent as, well we talked, wrote some things down, might as well share it.
And then the principles, there were a lot of different practices in the room. So some of what I would say the beauty of even the values page is the humility at the top is it's still active voice. We are uncovering not, hey all peasants, we figured it all out. No, we're still uncovering it. And the other thing is by doing it, because I'm still an active coder. And plus we value this more on the left, more than on the right. Some people might say it's a little ambiguous or a little fuzzy, but that's also a sign of humility and that it's not A or B. And it really is fuzzy, and you need to understand your context enough to apply these things. So from a defense department contracting point of view, certainly three of the four bullets were really important to me because I learned... Sure, we did defense department contracting. But it's way more important to develop a rapport with the customer than it is... Because by the time you get to the contract you've already lost, which goes along with developing a rapport with the customer, the individual.
And one of Peter Codes, when we worked with customers and whatnot, one of our mantras was frequent tangible working results, AKA working software. You can draw a lot and you can do use cases for nine months, but if you don't have anything running, it's pretty, I would guess risky that you don't have anything, no working software yet. So it really was I think an opportunity to share the fact that some people thought two weeks and other people thought a month. Even some of the print principles had a pretty good wide ranging flexibility so to speak. That I think is really important to note.
Amaar Iftikhar:
Yeah, no, absolutely. And it makes sense. Did you or anyone else in the room at that time ever imagine what the impact downstream would be of the work that was being done there?
Jon Kern:
Not that I'm aware of. I certainly did not. I remember a couple times in my career walking in and seeing some diagrams when I worked with the company Together Soft, and we'd build some cool stuff and I'd see people having some of the... Oh yeah, there's a diagram I remember making on their wall. That's kind of cool. But nothing near how humbling and sort of satisfying it is. Especially I would say when I'm in India or Columbia or Greece, it almost seems maybe they're more willing to be emotional about it. But people are, it's almost like they were freed by this document. And in some sense this is a really, really tiny saying it with the most humility possible. A little bit like the Declaration of Independence, and the fact that a handful of people... And the constitution of the United States. A handful of people met in a moment of time, never to be repeated again and created something that was dropped on the world so to speak, that unleashed, unleashed a tremendous amount of individual freedom and confidence to do things. And I think in a very small, similar fashion, that's what the manifesto did.
Amaar Iftikhar:
As you mentioned, there was a point in time when the manifesto was developed and that was almost over 20 years ago. So now the way of working, and the world of working has drastically changed. So what are your thoughts on that? Do you see another version coming? Do you think there are certain updates that need to be made? Do you think it's kind of a timeless document? I'd love to hear your thoughts on that.
Jon Kern:
Yeah, that's a good question. I personally think it's timeless and I welcome other people to create different documents. And they have. Alistair has The Heart of Agile, Josh Kerievsky's got Modern Agile.
There's a few variations of a theme and different things to reflect upon, which I think is great. Because I do believe, unlike the US Constitution, which built in a mechanism to amend itself, we didn't need that. And I believe it captured the essence of how humans work together to produce something of value. Mostly software, because that's what we came to practice from, is the software experience. But it doesn't take a lot of imagination to replace the word software with product or something like that and still apply much of the values that are there with very, very minor maybe adjustments because frequent tangible working results.
There might have to be models, because you're not going to build a skyscraper and tear it down and say, "Oh, that wasn't quite right," and build it again. But nonetheless, there are variations of how you can show some frequent results. So I think by and large it's timeless. And I would challenge anybody. What's wrong with it? Point out something that's somehow not true 20 years later. And I think that's the genius behind it was we stumbled on... And probably because most of us were object modelers, that's one of the things we're really good at, is distilling the essence of a system into the most critical pieces. That's kind of what modeling is all about. And so I think somehow innately, we got down to the core bits that make up what it is to produce software with people, process and tools. And we wrote it down. That's why I think it's timeless.
Amaar Iftikhar:
Yeah, no absolutely. I think that was a really good explanation about why it's timeless. I think one of the principles that comes to mind in a kind of modern hybrid or flexible working arrangement is one of the principles talks about the importance of face to face conversations. And in a world now where a lot of conversations aren't happening physically face to face, they might be happening on Zoom. Do you think that still applies?
Jon Kern:
Yeah, I think what we're finding out with... Remote was literally remote, so to speak, back 20 years ago. I was working with a team of developers in Russia and we had established enough trust and physical... I would travel there every month. So kind of established enough of a team, and enough trust in the communication that we could do ultimately some asynchronous work because different time zones. And me being in the east coast. 7:00 AM in the US was maybe 3:00 PM in Russia if I recall. St. Petersburg. So we were able to overcome the distance, but it's hard to beat real life. And I would often sometimes even spar a little bit with Ron Jeffries that on the one hand you could say the best that you can do is in person. But on the other hand, I could argue a little bit of some of the remoteness makes things... You have to be a little more verbose, possibly a little more precise, but also a little more verbose. A little more relaxed with... You might take a couple of passes to get something just because, I mean there are two time zones passing in the night. But that was based off of some often initial face to face meetings, and then you could go remote and still be successful and highly effective.
So I think it's important that teams don't just say that they can still do everything. And zoom is way better than 20 years ago, admittedly. Zoom gets, at least you can see a face. But nothing replaces the human contact. And I think also for wellbeing, I think human contact is important. So I would still say that the interaction aspect in the manifesto is still best served with a healthy dose of in-person. And that's kind of the key about most things in Agile. It's to me it's about pragmatism, and not just being dogmatic but rather, what might work better for us? And even experimenting with try something a little bit and see how that works. So even how you treat the manifesto, you should treat it in an Agile manner so to speak.
Amaar Iftikhar:
Yeah, no absolutely. That's a great point. On that note, as an Agile consultant or the Agile guy, what have you seen are the best practices or what works, what doesn't work for distributed teams?
Jon Kern:
Well I think the things that are most challenging that I've run across big companies and even smaller ones is that... I don't know if it's natural, God forbid if it's natural, but tendencies that I've seen in some companies to set up silos where you're the quality control, you're the UX, you're the front end, you're the back end, makes my headwater explode. Because that's building in a lag and building in communication roadblocks and building in cooperation which is handed offs from silo to silo, versus collaboration. So I've seen more of that. And I get it, you might want to have a specialty, but customer doesn't care. Customer wants something out the door. If I showed up and I'm going to pull a feature off the stack, what do you mean I can only do part of it? I don't get that. And yeah, I know I'm not an expert in everything but we probably have an expert that we can figure out what the pattern is. So I find that sort of trend, I don't know if it's a trend, but I find that's a step backwards in my opinion. And it's better to try to be more cross-functional, collaborative, everybody trying to work to get the feature out the door, not just trying to do your little part.
Amaar Iftikhar:
Yeah, a hundred percent. I think knocking on silos is a big part of being agile, or even being digital for that matter. And often the remedies for it too are there at hand, but it's a lot harder to actually be practical with it, to actually implement it in an organization, a living, breathing business where there's real people and there's dynamics to deal with, and there's policies and processes to follow. So I guess as generic as you can be, what is your thought as an Agile consultant to a business that's kind of facing that issue?
Jon Kern:
One of the things that... Adaptive is what my colleague John Turley has really opened my eyes to. I tend to call it the secret sauce, or the missing piece to my practice. And it has to do with individual's mindset and what we call vertical development. So it might sound like weird wishy-washy fluffy stuff, but it's actually super critical. And I've always said people, process, and tools for, I want to say since late nineties probably, I mean a long time. And the first I've been able to realize why sometimes I would have just spectacular super high performing teams and other times it'd be just really, really well performing but not always that spark and sometimes kind of like, eh, that was a little meh. And a lot of it comes down to where people lie on in terms of how they make their meaning and what their motivational orientation is, command and control versus autonomy.
So what we do is we've learned that we can help people first off recognize this exists, and help people with what we call developmental practices. Something that, even the phrase, you probably heard it, like safe experiments. Failure, or trying something and failing. Well if you chop someone's head off for it, guess what? They're just going to probably stay pretty still and only do what they're told, not try to... I have a super high dose of autonomy in me, so I've long lived by the, better to beg forgiveness than ask permission, and always felt as long as I'm trying to do the right thing to succeed and do the best for the company, they probably won't fire me if I make a mistake. But not everybody has that amount of freedom in the way they work. So you have to help establish that as management, and that's a big thing that we work with, with teams.
And then we also start with the class. If you've ever watched office space, and if you haven't you should, but the, what is it that you do here? So there's a great, the consultants Bob and Bob coming in, the efficiency consultants, "So Amaar, what is it that you do here?" But literally that's something, whether we're helping teams build a new product, is okay, what's the purpose? What's the business purpose of this product? What is it that you do here? What do you want to do with this product? What value does it provide? Same thing with anything you're working with as a team. And that's why whether it's software, producing some feature that has an outcome that provides value to the customer, or some product. But the point is if you don't understand that, now it's making, the team is going to have a real hard time being able to make decisions which are helping us move forward.
So if you help everybody understand what it is we're here to do, and then try to get the folks that might reflect all the different silos if you're siloed, but all the different elements. How do we go from an idea to cash, so to speak, or idea to value in the customer's hand? And have a good look at that. Because there are so many things that just sort of... Technical data often creeps into software code bases. And the same thing, we sort of say the organizational debt, the same thing can happen. Your process debt. You can just end up with, all right, we want the development team to go faster, John and company, can you come in and help coach us? We want to go agile. Sure, okay yeah. All right. We roll up our sleeves, we look around and after an initial kind of value stream look, like, wait I'm sorry but there's a little tiny wedge, it's about 15%, that's the development. And then you spent the 85% thinking about it.
Let's pretend we could double the speed of development. Which was initially the... Yeah, we need the developers to code faster or something. That's a classic. And no you don't, you need to stop doing all this bullshit up front that's just crazy ass big waterfall project-y stuff with multiple sign-offs. And matter of fact, one of the sign-offs, oh my gosh it only meets once a week, and then if you have a typo in it, you get rejected. You don't come back for another... Are you insane? You spent eight months deciding to do eight weeks worth of work. Sorry, it's not the eight weeks. So things like that, what I recommend anybody self inspect is try to... If you're worried about your team, how you can do better is just start trying to write down what does your process step look like and what is a typical time frame?
How much time are you putting value into the... Because a lot of times people batch things up in sprints. That's a batch, why are you putting things in a batch? Or they have giant issues. Well that's the big batch. So there's lots of often low hanging fruit. But to your point, it's often encrusted in, this is the way we work and nobody feels the ability to change or even to stop and look to see how are we working. So I think that's where we usually start is let's see how you actually work today. And then while we're doing that you can spill your guts, you can tell us all the things that hurt and that are painful and then we'll try to design a better way that we can move towards, in terms of working more effectively. Because our goal is to help teams be able to develop ways to do more meaningful and joyous work, really. Because it's a lot of fun when it's clicking and when you're on a good team and you're putting smiles on the customers' faces, it's hard to almost stay away from work because it's so much fun. But if it's not that, if it's drudgery and you're just a cog in the machine and stuff takes months to get out the door, it's a job. It's not that much fun.
Amaar Iftikhar:
Yeah. A lot of the points that you mentioned there strongly resonated with me, and the common pain points. It sounds like you've kind of seen it all. And by the way if you haven't seen office space, definitely need to watch it. It's a really good one. You've mentioned now a lot about of the element of the challenges that a distributed team faces. Now I want to flip it over and ask you what does the perfect distributed team look like today that lives and breathes agile values?
Jon Kern:
Yeah. I don't know if you can ever have such a thing, a perfect of any kind of team. So I would say harking back to the types of distributed teams that I've worked with, and this goes back to the late nineties. So I've been doing this for a long, long time. Only really done remote, whether it was with developers in Russia or down in North Carolina, or places like that. And I think that the secret was having a combination of in-person... If you want to go somewhere as a group, there are things you can do to break the ice, to establish some, what you might call team building type activities.
And not just, hey let's go do a high ropes course and be scared out of our wits together. But rather also things that are regarding why are we here, what are we trying to achieve? And let's talk about whether it's the product we're trying to build, and take that as an opportunity to coalesce around something and get enough meat on the bone, enough skeletons of what it might look like. Because there's good ways to start up and have a good foundation. And that's part of what I've been practicing for decades. If you get things set up properly with understanding that just enough requirements, understanding... And I do a lot of domain modeling with UML and things like that, just understanding what the problem domain is that we're trying to solve to achieve the goals we're looking for, have a sense of the architecture that we want. So all those things are collaborative efforts.
And so if you have enough of a starting point where you've worked together, you come in and, let's say you even had to go rent someplace, because nobody lived near office, so you all flew somewhere. I mean that's money well spent in my opinion. Because that starts the foundation. If you've broken bread so to speak, or drank some beers, or coded together and did stuff, and then you go back to your remote offices to take the next steps and then realize when you might need to meet again. So that's really important to understand that the value of establishing those relationships early on so that you can talk bluntly. And I have some good folks that I run a production app for firefighters since like 2006.
Amaar Iftikhar:
Yeah, very cool.
Jon Kern:
And that friend that I've worked with, we are so tight that we can... It makes our conversations, we don't have to beat around the bush, we don't have to worry about offending any, we just, boom, cut to the chase. Because we know we're not calling each other's kids ugly. We're just trying to get something done fast.
And building that kind of rapport takes time and effort and working together. And that's what I think a good successful distributed team, you need to come together every so often and build those relationships and know when you might need to come together again if something is a problem. But that I think is a key to success is it shortens the time. Because you may have heard of things like the group forms, if this is performance on the Y axis they form and they're at some performance level, then they need to storm before they get back to normal, and before they start high performing. So it's this form, storm. You get worse when you're storming. And storming means really understanding where we're at. When we argue about, I don't think that should be inheritance, Amaar. And then you're like, "Oh bull crap, it really..."
And again, we're not personal, but we're learning each other's sort of perspectives and we're learning how to have respectful debates and have some arguments, so to speak, to get to the better place. And I've worked in some companies that are afraid to storm, and it feels like you're never high performing.
Everyone's too polite. It's like, come on. And I love when I worked with my Russian colleagues. They didn't give a crap if I was one of the founders. And I'm glad, because I don't want any privilege, I don't want anything like that. No let's duke it out. May the best ideas win. That's where you want to get to. And if you can't get there because you don't have enough of a relationship, and you tend not to say the things that needed to be said because you're being polite, well it's going to take you really long to succeed. And that's a lot of money, and that's a lot of success, and people might leave.
So I think the important thing is if you're remote, that's okay, but sheer remote is a real challenge. And you have to somehow figure out, if you can't get together to learn how to form and storm, and build those bonds face to face, then you need to figure out how to do it over Zoom. Because you need to do it, because if you don't, if you never have words, then trust me, you're still not high performing.
Amaar Iftikhar:
Yeah, I kind of feel like being fully remote now is being offered as almost a competitive advantage to candidates in the marketplace now, because it's a fight for talent. But if I'm understanding correctly, what you are saying is that in-person element is so important to truly be high performing and those ideas kind of contradict each other, I feel.
Jon Kern:
Yeah. And again, having been remote since the late nineties, I've been doing this a long time. And commuting to Russia is the longest commute I ever did, for three years. I mean that's a hell of a long flight to commute there over seven times, or whatever the hell it was. Anyway, I used to say that that being remote is not for everyone, because it really isn't. I mean you have to know how to work without anybody around, and work. I mean it has its own challenges. And yeah, it might be a perk, but I think what you need to do is look at potentially what the perks are and figure out too, can I fold them into... It doesn't have to be all or nothing. And I think that can be a easy mistake to make maybe is to, all right cool, we don't have to have office space. That's a lot of savings for the company. Yeah, but maybe that means you need to have some remote workspaces for occasional gatherings, or figure it out.
But yeah, I think even... And certain businesses might work differently. In the beginning of building a product, I want to have heavy collaboration and I want to get to a point where it's almost, I feel like the product goes like this where once you get things rolling and you kind of get up, get some momentum going, now the hardest thing to do is be in front of an agile team, whether they're in-person or remote. Once things are rolling and rocking and kicking and it's like everything's clicking, you can just bang out features left, like boom, boom, boom. Yeah, okay then we probably need to be...
Unless we've got ways that we're pairing or things like that. I will say when we're together, mobbing is easier. I'm sure there's ways to do it remote, but being in a room, I don't know, it's a lot easier than coordinating over Zoom. You just, hey there's this problem, let's all hang out here after standup because we're just going to mob on this. So it doesn't take a whole lot versus anything remote, there's a little extra, okay, we've got to coordinate, and even different times zones, gets even worse. So yeah, don't get carried away with remote being the end all be all. Because I have a feeling there's going to be a... I would wager there will be a backlash.
Amaar Iftikhar:
And I'll take that back coming from the Agile, the person who does this day to day who helps teams become agile, I'll definitely kind of take your word for it. Plus with my experience too, I've seen nothing really beats a good white-boarding session. That is really hard to replicate online. I mean we have these amazing tools, but nothing quite mimics the real life experience of just having a plain whiteboard and a marker in your hand. That communication is so powerful.
Jon Kern:
Great point. You're so, right, because I had just with the one company that I was with for five years, we were doing high level engineered to order pump manufacturing sales type tool for... So it was my favorite world because it blended my fluid dynamics as an aerospace engineer, plus my love for building SaaS products, and building new software and things like that. And even having a young, we would interview at Lehigh University and we'd have some young graduates that would be working with us, and being able to bring them into the fold, and there was a room behind where my treadmill was and we'd go in there, we'd have jam sessions on modeling and building out new features. And man, you're right. Just that visceral three dimensional experience. Yeah, Miro's great. Or any other kind of tool, but yeah, it's not the same. You're absolutely right. That's a great point. You're almost making me pine for the good old days. [inaudible 00:42:04]
Amaar Iftikhar:
I think the good old days very much still exist. I think even now, it's kind of been a refreshing time for me to be with Easy Agile. I've only been here for just under two months now. And there's a strong in-person dynamic. And again, it's optional, where if people are remote or they're hybrid or they need to commute once in a while, it's a very understanding environment. But once you're in the office or you're in person, you kind of feel the effect you were describing, you're motivated to deliver for the end customer. You just want to come back. It's an addictive feeling of, I want to be back in person and I want to collaborate in real time in person.
Jon Kern:
That's beautifully said, because that's... One of the companies that we're beginning to engage with in South Africa, they're at this very crossroad of struggling with, everybody's been remote, but boy, the couple times we were together, got so much done. And you're describing the flame of, the warmth of delivering and let the moths come to the flame. I mean nurture it and then fan the flames of the good and let people opt in and enjoy it. And still sometimes, yeah, I got to say home, I got the kids or the dog, that's okay too. But giving the option I think is where we're going to head. And I believe the companies that are able to build that hybrid culture of accepting both, and neither mandating one nor the other, but building such a high performing team that basically encourages people to opt into the things that make the most sense at that time. And I think that those companies will rule the day, so to speak.
Amaar Iftikhar:
Yeah, absolutely. It's been so nice to chat with you John, and I've really enjoyed this. I want to leave the audience off with one piece of advice for distributed agile teams from you. We've talked a lot about the importance of in-person collaboration. We've talked about the principles of the agile manifesto. Now, what would the one piece of advice be when you're thinking of both? When you want the agile manifestos to be something that's living and breathing in distributed agile teams, what one piece of advice can you give businesses today right now who are going through the common struggles? What can you tell them as that last piece of advice?
Jon Kern:
Well, I think kind of a one phrase that I like to use to capture the manifesto is, "Mind the gap." In my sort of play on words, what I mean is the gap in time between taking an action and getting a response. Whether it's what do we do about the office, what do we do about remote, what do we do about this feature, what do we do about this line of code? The gap in time is, it's sort of a metaphor about being humble enough to treat things as a hypothesis. So don't be so damn sure of yourself one way or the other about the office or remote or distributed. But instead, treat things as a hypothesis. Be curious and experiment safely with different ways and see what works. And don't be afraid of change. It's not a life sentence to, you got to run your business or your project or your team one way for the rest of your life. No. Don't tell the boss, but work is subsidized learning. I never understood people who just keep doing the same thing because they weren't given permission. Just try it. So that's what my departing phrase would be regarding making those decisions. Mind the gap and really be humble about making assumptions, and test your hypotheses, and shorten the gap in time between taking actions and seeing a reaction.
Amaar Iftikhar:
Oh, that's awesome. Thank you. I really wish we could let the tape roll and just keep talking about this for a couple more hours, but we'll end it right there on that really good piece of advice that you've left the audience off with. Jon, thank you again for being on the podcast. And we've really, really enjoyed hearing you and learning from your experiences.
Jon Kern:
Oh, my pleasure. Any time. Happy to talk another couple hours, but maybe after some beers.
Amaar Iftikhar:
Yeah.
Jon Kern:
Except it's your morning, my evening. I'm going to have to work on that.
Amaar Iftikhar:
Yeah.
Jon Kern:
My pleasure, Amaar.
- Text Link
Easy Agile Podcast Ep.11 Dave Elkan & Nick Muldoon on building Easy Agile
On this episode of The Easy Agile Podcast, join Nick Muldoon and Dave Elkan, Co-CEO's and Co Founders of Easy Agile. As they look forward to the next phase of growth for the company, they wanted to take this opportunity to reflect on their journey so far.
Nick and Dave talk growing a start-up in regional Australia, finding the right people, sustaining a positive team culture and the importance of having values driven teams."Our purpose is to help teams be agile and in doing that, we're doing that for ourselves, we're constantly trying to learn and adapt and experiment with new things. I hope that was a useful little tidbit and journey from Dave and I on how we got Easy Agile to this point."
- Nick Muldoon, Co-CEO, Easy Agile
"There's these funny little hacks and analogies and I think that's a longterm vision thing. If you are running a business which doesn't have that longterm vision and purpose, then you can go actually in multiple directions at once, and you're not going to make any progress."
- Dave Elkan, Co-CEO, Easy Agile
Be sure to subscribe, enjoy the episode 🎧
Transcript
Nick Muldoon:
Good day, folks. Nick Muldoon with co-founder, co-CEO of Easy Agile, Dave Elkan. Before we kick off, we'd just like to do an acknowledgement to the traditional custodians of the land on which we broadcast and record today, the Wodiwodi people of the Dharawal Nation. We pay our respects to elders, past and present, and extend that same respect to any of our aboriginal folks that are listening today.
Nick Muldoon:
Dave, just a bit of a reflection on five and a half years of business?
Dave Elkan:
Business? Yeah, a rollercoaster. It's been great fun.
Nick Muldoon:
It is a rollercoaster, isn't it? I guess, where's the best place to start? The best place to start is at the start.
Dave Elkan:
Yeah, I mean we can go before the start. There's always a good prequel. We can do a prequel episode later, I guess. But I guess the earliest I remember working with you, Nick, was at Level 15 at Kent Street, at Atlassian. There was this redheaded guy down the one end of the building, working on Atlassian GreenHopper and I was busy working on the Kick-Ass team at the time, building the new issue navigator, which is now the old issue navigator, back in 2011. And then you screwed off to San Francisco and I followed eventually, and then we hung out there for a while, didn't we?
Nick Muldoon:
Yeah, I remember that because we sat down, I was back to get married, and we sat down and had a coffee and a yarn about you and Rin relocating to San Francisco and how it had been for Liz and I, and what the process was like and all that sort of stuff.
Dave Elkan:
That's a great opportunity to acknowledge our lives in this amazing journey as well and if it wasn't for those, we probably wouldn't have gone to San Francisco in the first place, because a large part of the promotion of going overseas and doing that for me anyway, and for yourself, I'm pretty sure.
Nick Muldoon:
Yeah. Well, Liz was this big conversation of go overseas and experience something new and I was quite comfortable in Sydney and enjoying my role with product management at Atlassian, but it was really a push to try and experience and do something a bit different.
Dave Elkan:
Absolutely, same here. And you were there for over four years, in San Francisco, and I was there for three. But you came home, you got married, and I just grabbed you for a coffee and we sat there in Martin Place and had a chat, and you said, "Yeah, it's great. Come over, you can stay with me for two weeks." And I'm like, "Oh, I barely know you."
Nick Muldoon:Yeah, but it was so much. I mean, even not knowing Liz or I, it was way better than the alternative. So for folks listening in, the Atlassian apartment, at the time, was in a fairly rough part of The Tenderloin in San Francisco, and it probably wasn't the greatest introduction if someone was relocating to San Francisco.
Dave Elkan:
No. But to cut a long story, there's a lot of good stories here I'm sure we can tell one day, but eventually, we both had daughters in San Francisco and we wanted to be home and closer to family. Then we came home to Sydney and found that the traffic is 20% worse or 50% worse than when we left and we were uprooted. So once you've been uprooted, you've got to plant yourself back somewhere and it's quite easy to change at that point, and you've chosen to go outside of Sydney.
Nick Muldoon:
Yeah, this Wollongong regional lifestyle.
Dave Elkan:
Yeah, where you can have a full block of land to yourself without breaking the bank and you can, relatively speaking, like times have changed a bit in that space, but since then, that's what we were chasing, wasn't it? And we looked at Newcastle, and-
Nick Muldoon:
Looked at Newcastle, looked at Brisbane, Adelaide, we even went through Wagga Wagga. We had the most amazing Indian meal in Wagga Wagga, we were almost like, "This is the place. If we can get food like this in Wagga, we're sweet." Bit too cold, but we ended up settling on Wollongong, in large part because of the proximity to the beach and the Early Start Discovery Space for the kids and just a pretty cool, chill place to raise a family. There are aspects of it as well, I think, that really reminded Liz and I of San Francisco. We used to go to the farmers market down at the Ferry Building a lot on a Saturday morning, and we found the farmers market on a Friday in Wollongong on Crown Street North, so there were these similarities to kind of enable us to transfer from one city to the other fairly easily.
Dave Elkan:
Yeah. It's a pretty easy place to live and to be. The way I like turn it, is it's just far enough away from Sydney.
Nick Muldoon:
Yeah, a nice little national park in between.
Dave Elkan:
That's right, it can't really encroach on us, it's not allowed. You can't build there so you're always going to have that buffer. But I do remember going back to Sydney for a niece's birthday and having been charged $9 an hour for parking at the beach, considering you don't even have a parking sticker anymore because I wasn't a resident, and I was like, "Wow, it's really expensive." But for anyone coming to Wollongong or the other way, you can park for free at the beach. That's just kind of like a good litmus test of the difference that we're talking about here.
Nick Muldoon:
Mm-hmm (affirmative). Yeah, I guess this regional life, like we didn't really have a tech industry here. We come from Sydney where, 10 years ago, there was this emerging tech scene and SydJS, SydCSS, other meetups up there, and in San Francisco we were thrust right in the middle of it. I remember, we were chatting the other week about a meetup where we met, the Ruby Creator at a Heroku meetup, I think it was, and a session on [detrace 00:06:17] at that company that's gone bust now, whose name I can't even remember, but we were in the heart of all the meetups in San Francisco. Then in Wollongong, there was none of it, and so it was like a question of what could we do to build a community here as well, try and meet other like minded folks?
Dave Elkan:
Yeah, it was definitely that desire, wasn't there? And we set out to do that, and I think it was Rin who termed it Siligong. I remember we were actually talking about Siligong Valley before we actually left, and we just decided to make that the name of the community. I was actually looking back on my old emails the other day and I was like, "Oh, we actually talked about Siligong before being in Wollongong," so that's pretty cool.
Nick Muldoon:
I remember early days because I think you and Rin returned on flight with [Umi 00:07:08], and Umi was six or eight weeks old.
Dave Elkan:
Yeah, October.
Nick Muldoon:
If I'm not mistaken, I dropped you at your mom's place so that you could catch up with your mom and Ken and that was kind of like home base. And it was a couple of months after that or something, where we finally had you down here. I think you stayed with Liz and I when you came down here-
Dave Elkan:
Yeah, again for two weeks.
Nick Muldoon:
... for another couple of weeks, and we were really talking about the genesis of what was, at the time, what was termed Arijea Products, and a brand that we never ended up sticking with. What do you remember about those early days and trying to get the business off the ground?
Dave Elkan:
Actually, come to think of it, you were staying in, not Coniston, [Carmila 00:07:59], it was actually less than two weeks because we all had little kids and it was just a bit crazy. So I think Rin and I organized... we came down and did inspections and we stayed with you whilst we're doing that, and then we were able to secure a place in Fairy Meadow and we moved down, so we were going back and forth a bit at that point. And then it was this six months of just literally... I didn't have a bike, I just walked to work, which is super new to me. I've always caught the bus or ridden my bike.
Dave Elkan:
Some of you may know I've never commuted to work and I hopefully will never have to do that, and we've engineered our lives around that kind of concept. But I think that it was really great, I was just living within two kilometers' walk of work, and that was for at least the first six months until I moved to Balgownie, but it was great time of my life and we had a brand new baby and just concentrating on the business, trying to [crosstalk 00:09:00]-
Nick Muldoon:
I remember, we really didn't have much of an idea of what we were doing in early days. We chased down one area and we said, "No, that's not appropriate," and then we kind of turned our attention to something else.
Dave Elkan:
Yeah. We were chasing our tails a little bit. We, at one point, had five products with two people.
Nick Muldoon:
That's right.
Dave Elkan:
I think that, that's too much, but with good conversations with the fellows around us at IXI, that we were able to have... like they were asking good questions and I remember Rob and Nathan asking us, "What is it you're good at?" And I think it was Rin, was like, "Okay, you've got this app idea, who're you going to market it to? Look at your networks." And it was, all those arrows started pointing towards Agile.
Nick Muldoon:
Yeah, I think it was this idea that Rin had like, "You can build it and they will come, or you can figure out your go-to market and your distribution piece, and what's the audience that you've already got, and how do you leverage the audience that you've already got in Agile Software Development to kind of seed and build that audience, and get some momentum?" And that's what really kicked us along and got us going. If I'm not mistaken, I think we'd actually... not that we had a lot of outgoings, but I think we were actually break-even by June of 2016, and it was kind of like this, "Hurray," moment because we were not going to have to get on the train and commute to Sydney for working at Atlassian or something like that. We'd found product-market fit and we could kind of pursue and go to the next stage.
Dave Elkan:
That's right, yeah. There's a lot in that story as well, like how we found product-market fit and the steps towards that and lots of learnings from that time as well, which is great to share eventually, I guess, but we might go down a rabbit hole if we jump into that one. But I certainly do remember good considered conversations that were held by lamingtons and tea in the Mike Codd building at the Innovation Campus at University of Wollongong, where we started. And that was really just a time to... it felt different to my prior, at the time 15 years of experience, where you actually, it's okay to stop and talk and think about what you're doing, whereas in the past, it's just been, "Go, go, go, build this thing." And it's like, "Oh, okay," so that was really refreshing for me and I think that, that was a really good step in opening up what became the story map, which was our first really successful product.
Nick Muldoon:
Mm-hmm (affirmative). You mentioned the lamingtons and tea, it was probably at least 50% of our time getting the business off the ground, was lamingtons and tea. It was chatting about stuff, it wasn't writing code, we didn't have customers to speak of. It was really trying to figure out what sort of market did we want to pursue, what solutions did we want to provide and what sort of business did we want to create? That was a large part of our time getting it off the ground.
Dave Elkan:
Absolutely. And for those listeners out there who don't know what a lamington is, it's actually a delicious piece of sponge cake dipped in chocolate sauce and then coconut, shredded coconut, so I know you can buy them in US, we actually did that at Atlassian and they were a huge success, especially because they had cream inside them as well, so real good for a cup of tea or coffee, whatever you take. But the thing is that it's a good idea to sit down with a co-founder and talk a lot more than you type, that's the kind of rule I took out of that.
Nick Muldoon:
It's interesting because it was kind of like that approach to talking instead of typing that was kind of like the genesis of one of our values, this engaged system, too. And I don't think you'd read Kahneman's book at that time, and that was something that came later, but even just this idea of, "Now, let's just take the time to think and process this sort of stuff," and the context [crosstalk 00:13:09]-
Dave Elkan:
No, I do remember. Sorry, yeah. I did a presentation at Lansing Summit in 2017 on Engaged System too.
Nick Muldoon:
16 or 17?
Dave Elkan:
16 or 17, I can't remember which one it is.
Nick Muldoon:
'16 because you went to Barcelona in '16.
Dave Elkan:
Barcelona, and that's what I did there, wasn't it? Yeah, so that was early on that I read Thinking, Fast and Slow, which I highly recommend.
Nick Muldoon:
And the context around this, for folks listening; in mid 2016, Dave had a nine month old daughter. My daughter was two years old and I had a newborn and you were to have... your number two was on the way, right? So we were building a business as we were starting and establishing our families as well, so it was, "Let's do it all," in a new city. Like, "Let's do it all at once."
Dave Elkan:
Yeah, you might as well, right? Just bite it all off and rip the Band-Aid off and get it done. I mean, my daughters were only 18 months apart, so that kind of... just get it over and done with. Get the hard part done and then you can go and enjoy yourself afterwards, just kidding. It's great to have lots of kids at a young age, like I really do miss that time. But yeah, we were pretty crazy, but we got through.
Nick Muldoon:
It gave us a constraint as well, didn't it? Because we couldn't burn the midnight oil, we couldn't flog ourselves from 05:00 AM to midnight because we simply did not have the energy and we had to get kids fed and bathed and off to bed and all that sort of stuff. So it brought a cadence and now that I reflect on that, there was another value that was kind of coming out of that, which was with respect to our balance and establishing balance in our lives.
Dave Elkan:
Yeah I do remember, sorry to interrupt, a tweet idea, I can probably dig it up, which was me hanging out cloth nappies or diapers on... it must've been, it was in Balgownie so that must've been after six months. But I was hanging out nappies and I must've been working from home that day or something like that, but that was just like me balancing life like that, with work. And I think it came back with like work, life, family balance or something like that. We would expand that to work life, family, community balance, is what we try and chase.
Nick Muldoon:
Mm-hmm (affirmative). How did we get on this journey around the values and kind of establishing the values? When was that in the life of the business?
Dave Elkan:
I can remember the place we were in, we were actually in our Crown Street office when we really sat down and really hunkered down into that, so that would've been 2018.
Nick Muldoon:
I think in November 2018, we held our first advanced Easy Agile, and that's where you ran the session, "What got us here won't get us there." And so at that point in time, we had the two products, we had Easy Agile User Story Maps and Easy Agile Roadmaps, and we had changed our brand from Arijea Products to Easy Agile, to kind of focus our energy on the Agile space. We divested the other three products that weren't focused on Agile, so we'd sold those off to another Atlassian Solution marketplace partner. I think that's where we started having these conversations around the next evolution of the growth of the business. Then it was in 2019 where we were back in Crown Street, back in the office, where we were having that conversation about codifying, establishing, writing down our values.
Dave Elkan:
That's right, and it's a highly valuable process to go through and to really just pause on the day to day, and really focus on it. That's something I've always had trouble with, like I've always got things to do, but once you just extract yourself from that process and zoom out and look at the company and what you've come up and what you hold dear, that's when you can really start having those conversations, but making it an actual thing. I think that you can't just do it on the side, you can't just do it as well as other things, it's really got to be like the priority as I like to say. Priority is not a plural, it doesn't make any sense if it's pluralized, but that should be the one thing you do in an ideal circumstance, like you just do it and really focus on it, because it's really hard.
Dave Elkan:
And it shouldn't, I guess not in one sitting, but at least when you do it, make it a serious thing because if they're real values and you live them, like they just are pretty immutable, they just keep moving forward with you. If you found you're not living them, then you should absolutely revisit them, but we've been lucky enough in that the values we put forward have stayed true and I really feel like, of all the companies I've worked at, even Atlassian, like these ones I've lived every day in very distinct ways.
Nick Muldoon:
Mm-hmm (affirmative). So what are the values we've got? We've talked about better with balance, and we talked about that a little bit. We also talked about engaged System 2 like this System 2 thinking. What are our values?
Dave Elkan:
Be the customer, give back, and [crosstalk 00:18:30]-
Nick Muldoon:
[crosstalk 00:18:30] was a big one, and commit to team. So better with balance, give back, be the customer, punch above our weight, Engaged System 2 and commit as a team. Go back to the conversation that we were having in 2017 around give back, that was something that was really System 2. How did we think about giving back to the community and what that meant to us as a company?
Dave Elkan:
I think it goes back to what you said before about the community in San Francisco we experienced and what we did here with Siligon and just making that a focal point for us to give back to the community. It doesn't build itself, like the community has to be actively built by somebody has to put their hand up and start it, and I think we did that. Since then, like we've enabled heaps of other people to be able to give back in a really easy kind of way like, "Let's host a meetup," "That's fine, here's our framework to go build that on." And also just the daily communication we have amongst each other on our Siligon Slack, which is just super valuable.
Nick Muldoon:
Super active, too.Dave Elkan:
Oh, super active, especially in lockdown, lots of people on there talking about all sorts of things.
Nick Muldoon:
I think maybe one of the other things, so Dave and I experienced this at Atlassian, which was this idea of the Pledge 1%, but in our first or second year of Easy Agile, Atlassian along with Salesforce and a bunch of other companies came together to actually codify and build the foundation around Pledge 1% and ask other companies to commit to that. And we made that commitment in 2017 if I'm not mistaken, to do Pledge 1% donations and now, where I guess we're kind of doing Pledge 2% donations, but what was the drive behind our Pledge 1% to Room to Read?
Dave Elkan:
It's in part laziness, because I really want a system to these kinds of things and unfortunately, when you're starting a business it's hard to dedicate the time and to think about that. So I took the easy System 1 option, which is to go with what we experienced at Atlassian, which was to back Room to Read, which is a great initiative to help ensure that young ladies, specifically in third world countries, get at least a higher education, get out of primary school, get into high school, and once they've gotten to that point, it's far more likely they're going to be independent. And with that kind of thing, like that investment, it's like restarting at the beginning and enabling countries and people to help themselves. If they're educated, that's a huge step in the right direction to both fighting overpopulation, climate change, all these things which benefit from those people doing well in life.
Nick Muldoon:
Mm-hmm (affirmative). Yeah, continually improving their lot in life, right? Like raising standards of living through education.
Dave Elkan:
That's right.
Nick Muldoon:
And if we think about punching above our weight as one of these other things, I mean I remember that was something that we talked about before we wrote down our values, that was something that we really did focus a lot of energy on. You mentioned before, there were two of us and we had five products in the marketplace. I'm not exactly sure that was a great example of punching above our weight, because we might've struggled a bit, but what are some examples of where we've punched above our weight as a small team from regional Australia?
Dave Elkan:
One of our products that we built initially was really a bit of a thorn in my side, it was continually breaking and it wasn't playing to my strengths, which is traditionally front end development. So after that and getting burned by that and having to stay up all night and fix it, I opted towards apps which are more front end focused, and so we've built Easy Agile User Story Maps and Easy Agile programs and Easy Agile Roadmaps primarily as front end apps. As a matter of fact, Easy Agile Roadmaps, for the first two years, didn't even have a server, it was just a static file in a bucket in CloudFront. That's the way Atlassian Connect works, it allows you to host apps that way, and that really can't break, it's just providing a different view on Jira in essence, but architecturally, it's quite simple. So therefore, we could easily... that was a way of punching above our weight, which also allows better rebalance, so they're kind of complimentary in that respect. What other ideas [crosstalk 00:23:24]-
Nick Muldoon:
Yeah, if not much can go wrong, then you don't have to be on call, and you don't have to fix things out of hours, so you don't wake up blurry eyed and fat finger and have a bug the next day that compounds the problem.
Dave Elkan:
And if you take the analogy too far, like you could think punch above your weight is like being able to punch someone really hard and then knock them over, but this is more like just definitely, you're running around the big [fur 00:23:44]. You're not even engaging in babble, you're just sidestepping it. That's why we've run those products, and until recently, we actually do have servers now for them, and once again, it's still very simple, but they're very well monitored so if something does go wrong, that we're on top of that.
Nick Muldoon:
I think one of the other aspects with respect to technology in punch above our weight, is we've quite often... I think maybe you mentioned before, with respect to Room to Read and the give back, the laziness, but we are lazy in certain respects and we just want to automate things. And I remember the XKCD comic that you share, with what is the right time to automate something and when do you automate it to get the return on investment that you want? But I feel like we've made some fairly good decisions around when to automate things and even around how we provide customer support or the old test and deploy, toying around with products, we've done these things at pretty good times so that we can deliver products to a global audience of a couple of thousand customers, from Wollongong out of timezone with those customers.
Dave Elkan:
Yeah. It's also being ahead of the curve as well, so I think Inception Week, which is something we do every fifth week now, we give up one week to provide the team with the space to explore new things. Amazing things have come out of that, which otherwise, if you would just week to week, week to week, you would never actually realize, but when it comes to mind is our dev container, which is a docket container which contains all of the parts which are required to develop our apps. So you just check out this one repository, run a script and it sets up your entire develop environment. It's a great way for the team to share the tools that help them punch above their weight, so it's a huge punch above our weight thing and that came out of Inception Week. So I think Inception Week's a punch above thing, and also the dev container's a huge punch above thing.
Dave Elkan:
We used to have so many problems with individual versions of this or that on everyone's computer, and now that's just all gone, it's never happening again, it's never come back to bite us since, and I think it's an overwhelming success. Sure, it does need an all new RAM and all new CPU, but it does... we'll get there, like it's going to get better.Nick Muldoon:
RAM and CPU are cheap, it's okay.
Dave Elkan:
You can never get time back, right?
Nick Muldoon:
Yeah, absolutely. So when we think about these things, how intentional do you think we were around the values in our approach to building and scaling a company versus things that just kind of happened?
Dave Elkan:
For a large part of the starting of the business, there was a lot of, "Just get it done," kind of mentality stuff, which has to happen. However, I want to hop back to when we started, everything was chaos. I remember this, early 2018, mid 2018, we'd come in on Monday, go, "What are we doing today? What's this week? Let's look at the backlog and have a look." And there was no forethought whatsoever.
Nick Muldoon:
And we'd kick a couple of things off the backlog and we'd just work through on that weekend. That was it, right?
Dave Elkan:
Yeah, pretty much. And so you proposed the idea, it was at the beginning of the year, it must've been 2018. Was it 2019? Either way, let's just do one week on clarity, which is our internal CI room, essentially, and just knock out a bunch of products and problems. That was the first time we started really focusing, because since we had so many products, I think we actually might've sold them by now at this point. Yeah, I think we definitely had. However [crosstalk 00:27:28]-
Nick Muldoon:
But we still had Roadmaps, Story Maps, Clarity Week, EACS, like we had other internal systems that we used and the team was actually growing beyond Dave and me, and it was growing. There was Jared and Satvik and Rob, and so the team was growing at that point in time as well. So it gave us the opportunity to put a number of people onto one problem for a period of time, like a week.
Dave Elkan:
That's right, and from that came this idea of focus, and we started doing focused sprints, so product focus sprints, which highlighted another terrible problem of run over, if you did run over in your estimates, then you would have to come back like in nine weeks or something and it was just [diabolical 00:28:12].
Nick Muldoon:That's right.
Dave Elkan:
So we dropped [crosstalk 00:28:14]-
Nick Muldoon:
What did we do? We did two weeks on Story Maps, two weeks on Roadmaps, two weeks on internal systems, two weeks on something and then one week on Inception Week?
Dave Elkan:
Inception Week. Yeah, I think [crosstalk 00:28:26]-
Nick Muldoon:
I can't even remember now, what that other thing was.
Dave Elkan:
It was nine weeks in total, wasn't it?
Nick Muldoon:
Yeah.
Dave Elkan:
[crosstalk 00:28:31] Roadmaps-
Nick Muldoon:
If you missed it and you didn't ship it, then we went onto the next product and moved that forward, and then we'd come back to it.
Dave Elkan:
In ages away. And it was super stressful for the team and we quickly destroyed that, the week we went with a more flexible approach to it, where we dropped the hard mandate of you have to exchange products now, we let them run over a bit and then we'd adjust the story points to the next one, blah, blah, blah. And then eventually, I'm scratching my memory, but essentially, we got to a point where we introduced opportunities, which was based loosely on Shape Up by Basecamp and we took a bunch of things from that, but most things of that didn't really gel with our way of working and our values.
Nick Muldoon:
I mean that whole opportunity cycle, we've evolved three or four times now.
Dave Elkan:
And they were ideally just two or four weeks of work, and then we'd do Inception Week and Tech Debt week, and we have a dedicated Tech Debt week as a mandate. We dropped that since, and we've got to now we have four weeks of work, which includes Tech Debt and then we have Inception Week, and that's kind of cool, right? Like we still have this mandate of Inception week, not Tech Debt week. That's the last thing; I feel like the mandates... because it's like kick starting your motorbike, you've got to really give a good kick and that's essentially what we've been trying to do over the last three years, is like get this thing running. I think we've-Nick Muldoon:
Built momentum.
Dave Elkan:
The engine is now running... yeah. The engine is now running and we're pulling the clutch out. It's just that the mandates slowly fall away and the team finds their own way, but I still feel that, that cycle is the most important thing, that five weeks where we stop, everyone knows what's happening. Because if it just runs off into the future forever, you can't compute that in your mind, but you can see forward five weeks and go, "I'm going to plan this work, it's not going to be done to a Nth degree because that's kind of a bit weird," it's just like, "Let's try and achieve this and let's bite off one bit at a time." Then we have a break with Inception Week, let our creative juices flow and then we'll come back to it the next round.
Nick Muldoon:
Right, so I have to call timeout here. So this is a sidebar for everyone listening at home; Dave just used this analogy of kick starting the motorcycle and then pulling the clutch out. So one of the things that Dave does tremendously well, is he grabs these analogies and he uses these analogies to simplify what I otherwise feel can be fairly complex kind of concepts, and simplify them and communicate them really nicely. That's not one I've heard before but there's a new one we can add to the repertoire, Dave. I love it.
Dave Elkan:
Thanks, mate.
Nick Muldoon:
What other sorts of things? Because I guess we're charting this journey over five and a half years, where it's gone from Dave and Nick and the addition of Satvik and Teagan and Jared and Rob and Brad, and a few people over time, to the point today where we are 27, 28 people. What are some of the other markers along the way, that we've kind of gone through, that have shifted or evolved how we operate? Like the Easy Agile operating system that we've talked about in the past.
Dave Elkan:
Well, it's something that we've just discussed in the execution kind of level. Obviously, every six months, everything just goes and explodes and you have to fix it, like there's always some major thing that happens every six months, and I feel like that's good and that's healthy, and that continue to run into those things. Either they're internal or external and I feel like we're dealing with an external one right now, which I don't really want to touch in this podcast, but I think that they're healthy for the business to adapt to. But certainly, I think in that time, like really understanding that it's the people that count, right?
Dave Elkan:
The business is in there, like it's a thing, but it's nothing without the people who worked for it, and it's in service of the people who work here, as well as the customers. And so that's something we've come out of it. What do you think, Nick? Like the cultural aspects of what we've built, what do you think stands out to you?
Nick Muldoon:
I certainly think there's these inflection points. I mean, I remember a conversation with Jared when we were in Crown Street Mall, and it was in 2019 and we were talking with the team around the kitchen table there, and we could get eight people around this kitchen table and we were talking about growing the team to take advantage of the opportunity and responding to requests from customers and all that sort of stuff. I think Jared said, "Well, I quite like it the way it is."
Nick Muldoon:
And then I fast forward to an interview with Jared, which went into the five year video that we saw just before Christmas and that was around his trajectory and how he's evolved and adapted professionally and personally along with the company. I think that's the story for all of us as team members, we've all kind of been on a journey together and we're all learning and adapting together. We do live, in many respects, we do live this Agile approach where we do reflect and we take the time and we think and we experiment with new approaches to getting work done.
Nick Muldoon:
Even, I think... and we've been talking about this a bit recently with respect to pace, that first version of our learning and development program, where we wanted to provide funding for people to go and pursue something that they wanted to learn about. But we got that out, "Hey, that was a morning's worth of work," we put out an L&D, people started using the L&D program, and we called it our Version one of our L&D program, and today we're on Version, I don't know, 1.4 or whatever it is, of our L&D program. There's a lot of things that have gone out and we tweak and we improve them over time to make them ever better and better suited, perhaps, to the current state of play within the team. Is that fair?
Dave Elkan:
Yeah, it is. It is, and I think that; A, I've never worked at a business who has anything like that, and where they actively encourage you to use it, spend the money, make yourself better. If you make yourself better, the team will get better, if the team gets better, the customers get better outcomes, and the company continues to improve, and it will be probably a better place for you to work in the future. So it's really a holistic kind of perspective, rather than, not narrow minded, but myopic or focused on just output. It's outcomes of output and I think that could be another value of ours, if we were to have seven, it'd be outcomes over output. So really stopping, having that permission to stop and think, and system to it and think about what it is you're trying to achieve, rather than just blindly doing stuff.
Dave Elkan:So from a developer's perspective, the fastest code is the code that doesn't exist, and so if you can do something differently, which doesn't require 100 steps or just decide, "Hey, this is really tricky right now, this bit of code we're trying to work on or this feature is really hard. Can we just delete the feature?" And we did it on notice, I know that sounds pretty bold, but quite honestly, that kind of discussion is really healthy to have. I want to encourage the team to think that way and I think that learning development is also something you can do to bring people into it, look at their trajectory as a way of gauging their abilities, and giving them really... throwing fuel on the fire in that respect and seeing them ramp up in their ability, and help those around them.
Nick Muldoon:
Yeah, so take us through that, because that's something that we definitely talked about a few times, like when we've been looking at candidates and in a hiring huddle around candidates, we've talked about those that are on a certain trajectory and that we think that we can accelerate that trajectory. Where did that come from?
Dave Elkan:
Where do thoughts come from? I'm not sure, that's a good question. I couldn't tell you, but I think it's pretty obvious when you look at someone's CV and you see... now, there's nothing wrong with people who have long tenured positions, but if you talk to someone and they can't really say what they've done in the last 10 years and they've donned that one position for 10 years and they haven't really got anything striking they can tell about how they've made that better, that kind of says a lot about that person. Maybe they would come in and they'd just coast... they're a coaster, right? If they're coasting, that's fine, it's their call, but at the same time, we look for people who are actively trying to make their impact bigger through their work, help those around them. And you can see that, you can see, "Oh, look. They've been at the same company, that's fine, but they've gone and done these different roles or they've seen this kind of improvement in their approach."
Nick Muldoon:
This comes back down to that article, that Financial Review article, the mid-career annuity, so this was an article that we must've been kicking around in 2016, 2017, and it was around a Japanese term, mid-career annuity. You could have 20 years of experience in a role or you could have 20 first years of experience, and I think early on, and maybe it still occurs these days, I think it probably does, but it felt like we were getting 20 quarters of experience. Over that five year period, there was always some big, new challenge that we needed to learn and adapt and incorporate into the business over the first five years. So we were always learning and adapting, and we wanted folks that were on a similar journey and they were learning and incorporating and adapting and experimenting themselves.
Dave Elkan:
Yeah, it's something definitely, that can be learned, and I think that if you bring on new stars, they can just get that, this is what they do by default because you've put them into that environment. But some environments, especially older companies, can be fairly stagnant and static, so that just reflects on people's CVs. Either there's some kind of reason why the company won't give them a promotion or give them opportunities to chase, how we have a different approach where we throw too many opportunities at people, I think sometimes, and I've seen people using their L&D so much, it is actually impinging on their better with balance value. I'm like, "Whoa, this is fantastic but don't forget you've got kids and you've got to help look after them," and [crosstalk 00:39:41]-
Nick Muldoon:
Temper your enthusiasm, yeah.
Dave Elkan:
Yeah. So that's something to look for.
Nick Muldoon:
Stopping and reflecting on five and a half years, what's the purpose of the business, what's the goal over the next couple of years?
Dave Elkan:
Have fun, learn, what about you?
Nick Muldoon:
Definitely learning.
Dave Elkan:
Stay in business.
Nick Muldoon:
Oh, yeah. Stay in business, sustainable growth is always a good one. I think that's important. Yeah, I don't know, it's interesting. I feel like some days, it can be really fun and other days, it's not fun at all. That's probably due in large part, like when we started this, we were not in service of anyone but ourselves and one another, and now I feel like we are in service of a team of people that are themselves in service of the customer because we've got a couple of thousand of them. So it's the responsibility and the accountability's changed, and the way that fun comes about is, these days... it used to be fun to have lamingtons and chat, and these days, typically, there's someone else in the crew that is organizing the event that often participate in that I find fun and enjoyable with the rest of the team, rather than being able to carve out that time and do that.
Nick Muldoon:
I remember when we roped in a bunch of folks from iAccelerate and we went into town and we'd go into town and we'd go and we'd get a Laksa in town and we'd get a bowl of Laksa. It's been harder to do that in the past 12 months, given the global environment and all that sort of stuff, so hopefully we can find a bit more of that in 2022.
Dave Elkan:
And maybe ramen. There's ramen now.
Nick Muldoon:Oh, and it's great, you know it.
Dave Elkan:
Yeah. I think refining what we do and continuing to think more about that, so specifically with the engineers, I like to use a goal based... goals are big at Easy Agile, I think you should talk a bit about goals, but we use them to help guide people in chasing down things they want to achieve, and we can align those things with what the business does to an extent. Then, you can actually go and achieve your professional and goals through the business and the business is the vehicle to do that, rather than having to it outside. That's really cool, like find that harmony there so both Easy Agile can succeed and the people who work here can succeed.
Dave Elkan:
I think it actually is quite difficult, like you go, "Hey, take a step back, think about what you want to achieve, give that to me, and then I'll see what I can do to change the course of the business to help you accomplish that. What can we do? Maybe there's a middle ground we can chase down together." And that's something new to me and I'm kind of using that instead of performance reviews so make sure you do your goals, people. [crosstalk 00:42:44]
Dave Elkan:
But yeah, also you've made sure, you want to look back in time and you want to see yourself in the future, reflecting with the team. When they've gone and moved on, [crosstalk 00:42:56]-
Nick Muldoon:
Oh, yeah. Absolutely. I was even chatting with Elizabeth Cranston this week and I was saying, "I can picture in the future, you're living down at Narooma down the coast and I can come down and have a cheese and biccies with the families and you're looking over the bay at Narooma or something, and we're reminiscing on this period of time at Easy Agile." I can totally see that. Yeah, I think it's great and I think just on the goals, the goals are important personally, and we've talked a lot about goals in the past, with respect to tenure vision for the families and that sort of stuff.
Nick Muldoon:
But it's also for the business, I remember we had okay hours in place from getting the business off the ground, we've revised them every year, we've learned and adapted a lot over the last couple of years in how we think about our objectives and our key results. And the fact that we write them on a quarterly basis and we review them on a quarterly basis, but we've got these objectives that align with a business goal that's three years out, and it all kind of flows. I mean, I think we're a lot more mature around that aspect of our... I don't know, would I say strategic planning? Vision goal setting over an extended time period? We're a lot more mature around that today than we were two or three years ago. That's really exciting as well. [crosstalk 00:44:33]
Nick Muldoon:
Come back to what you were saying before about the backlog. We'd come in on a Monday morning, and we go, "What are we going to work on this week?" And we kind of worked over a couple years, we worked it out so that, "Ah, here's the vision for the product." It was a longer term thing, and we've elevated that and it's not like, "Hey, what are we doing for the business this month?" It's now, "Here's our longterm trajectory for the business." We've been elevating that, that's pretty exciting, I think.Dave Elkan:
And at the same time, trying to get the team to lift their line of sight as well.
Nick Muldoon:
Mm-hmm (affirmative), mm-hmm (affirmative).
Dave Elkan:
And look out further afield, but not too far. You want them to be looking at what's happening next week and next month as well, but also what's the goal, what are we chasing down? What's the bigger picture? And I think that's starting to happen.
Nick Muldoon:
What's the analogy there about golf, Dave?
Dave Elkan:
Oh. No, can you tell me? I can't remember.
Nick Muldoon:
It was this analogy about golf, like you've got to look where you're going to hit the ball and you've got to look up. You don't want to look at the tee, you want to look beyond the tee so that you... not beyond the tee, beyond the hole, sorry. You want to look beyond the hole.
Dave Elkan:
That wasn't my analogy, that's why I don't remember, but I do remember someone telling us that one. But it's a good one, like it wasn't even an analogy, isn't that the literal thing that the golf tutor would do? It's like, "Where are you looking?" And then they go, "Oh, I'm looking at the hole." "No, no, you've got to look further than the hole. Look up where you want the ball to go, and then away it goes."
Nick Muldoon:
Yeah, raise your sights.
Dave Elkan:
Raise your sights, yeah. And if you are looking at your feet, then you're probably not going to go far, but if you do look up and take stock, you can probably... that's actually a soccer analogy I can give you, like from my soccer coach, like you've got to point your toe where you want the ball to go. And that's just the magic thing, it just works. You just put your foot next to the ball with the pointing at the corner of the goal you want it to go in and you kick it, and then it just happens.
Dave Elkan:There's these funny little hacks like that and I think that's a longterm vision thing. If you are running a business which doesn't have that longterm vision and purpose, then you can go actually in multiple directions at once, and you're not going to make any progress. I think a good analogy I read was like with a team, if you imagine all the team members are tied to a pole with a rubber band and they're all heading in different directions, the pole's not going to move because everyone's just... and the company's going to stay static and still. But if everyone just goes in the same direction, then it's going to move along.
Nick Muldoon:
Shift it, yeah.
Dave Elkan:
Yeah. And that's something that we've bitten off recently, is our purpose.
Nick Muldoon:
Mm-hmm (affirmative), to help teams be agile.
Dave Elkan:
Yeah. It's one of those funny moments when we we're talking about, and we talked about it, we set ourselves a deadline for the sake of a better word, like we had our planning session coming up in a couple of weeks, so we sat down and talked about it. And we went around and around in circles, trying to discover what it is, not to be agile, but just, what is Agile? And we know [inaudible 00:47:45], but we were trying to codify that in words. And when you said that, like it's being agile, it was kind of one of those... the way I like to describe it is, an upside down A-moment, which is our logo as you can see on Nick's jacket there.
Dave Elkan:
So when that was proposed to me, I was like, "No, that's so silly." But I was like, "Oh, but I love it." And I'm not saying that being agile is silly, but the fact that it's so simple, that's what I like about it, it's easy, it's simple, and there's a lot there if you dive into it.
Nick Muldoon:
Mm-hmm (affirmative). Yeah. Well, why don't we wrap it there? I think that's a good place to end.
Dave Elkan:
Yeah.
Nick Muldoon:
Our purpose is to help teams be agile and doing that, we're doing that for ourselves, we're constantly trying to learn and adapt and experiment with new things, being Easy Agile and as our team members here. So I hope that was a useful little tidbit and journey from Dave and I on how we got Easy Agile to this point, and some of the things that have been on our mind.
Dave Elkan:
Yeah.
Nick Muldoon:
Thank you, Dave.
Dave Elkan:
Thank you, Nick. That was fun.
Nick Muldoon:
That was fun. Oh, goody.