Easy Agile Podcast Ep.8 Gerald Cadden Strategic Advisor & SAFe Program Consultant at Scaled Agile Inc.

In this episode, we dive deep into the challenges of aligning teams with strategic goals across organisations of all sizes. From fast-growing startups to large enterprises, teams everywhere struggle with the same fundamental issue: translating high-level objectives into actionable work that drives real value.

Our guest Andreas Wengenmayer, Practice Lead for Enterprise Strategy and Planning at catworkx (the #2 Atlassian partner worldwide and #1 in EMEA), shares his 11 years of experience helping organisations bridge the gap between strategic vision and team execution.

Want to see these concepts in action? Andreas and Hayley hosted an interactive webinar where they demonstrated practical techniques for strategic goal alignment using Easy Agile Programs. Watch the recording here→

About Our Guest

Andreas Wengenmayer is the Practice Lead for Enterprise Strategy and Planning at catworkx, one of the leading Atlassian Platinum Solution Partners globally and the #1 in EMEA. With over a decade of hands-on experience helping enterprise teams scale agile effectively, Andreas specialises in bridging the gap between strategy and execution. His work focuses on guiding organisations through complex transformation programs, optimising portfolio planning practices, and helping teams adopt frameworks like SAFe with clarity and purpose. Known for blending pragmatic insight with systems thinking, Andreas brings stories from the field - ranging from fast-moving startups to complex, multinational enterprises.

Transcript

Note: This transcript has been lightly edited for clarity, readability, and flow while preserving the authentic conversation and insights shared.

Recognising the signs - when teams aren't aligned

Hayley Rodd: Awesome to have you here. So I'm going to start with a bit of a reality check. We've worked in organisations across the spectrum from really fast-growing startups to really big enterprises. From your experience, when you walk into a PI planning or quarterly planning session, and I'm sure they're pretty hectic, what are the telltale signs that teams aren't truly aligned on what success looks like?

Andreas Wengenmayer: That's a great question - one I hear frequently. You can imagine, especially post-COVID when teams returned to in-person planning sessions. Back in 2017, we'd have huge arenas with hundreds of people in one place. People are happy to see each other, excited to chat with colleagues from different locations. This became even more pronounced after COVID, when everyone was working from home more frequently. That's a good sign - the mood is positive.

But you also notice some teams under pressure. They'd rather be working on actual deliverables. They know they have to be there, and it takes two full days to complete all the planning. Meanwhile, they're carrying a mental backlog - technical debt, unfinished work from the previous PI, catching up on delayed items.

This is what I often observe: teams get bogged down discussing minor details. People debate specifics, and you can see they're frustrated about something deeper - but they're not addressing the root cause. This creates its own negative momentum and can derail otherwise solid planning sessions.

Teams get bogged down discussing minor details. People debate specifics, and you can see they're frustrated about something deeper - but they're not addressing the root cause. This creates its own negative momentum and can derail otherwise solid planning sessions.

Sometimes you have to step in and ask what's really underneath. What's the actual cause? People say, "Yeah, I have to be here because that's the format, but I'm not engaged." Maybe it didn't work well in the past and there's lingering skepticism.

The prevailing attitude then becomes: "This isn't really collaborative. Leadership plans from the top anyway. The outcomes are predetermined - here's the plan, just make it work and update your boards." When people feel they can't meaningfully contribute or influence direction, they simply go through the motions.

My favourite example happens at the end when teams must formulate their objectives. It becomes a box-checking exercise - create something that satisfies the coach or Release Train Engineer so everyone can "get back to real work."

What good alignment actually looks like

Hayley Rodd: You've touched on so many things there. I can imagine walking into that room and feeling the pressure. People getting caught up in minor details rather than talking about root causes, or not asking the five whys to get to that root cause. You also touched on getting buy-in across the organisation. When people are really nailing it, when alignment is really there, what does that room feel like?

Andreas Wengenmayer: Yes, I've fortunately experienced those environments, and they're actually more common than you might think. When companies genuinely commit to grassroots planning, truly investing the time it requires, and ensure teams aren't overwhelmed from the start with everything marked "priority zero," you create the foundation for successful planning.

When companies genuinely commit to grassroots planning, truly investing the time it requires, and ensure teams aren't overwhelmed from the start with everything marked "priority zero," you create the foundation for successful planning.

You can see it immediately in people's body language and interactions. The energy in the room is palpable. If people appear resigned or intimidated, afraid to speak up, that's typically a red flag. The opposite creates magic.

Think about high-performing teams, like being a Scrum Master with an exceptional group. The best teams aren't just collections of highly skilled individuals in specific roles.

The best teams are those who communicate openly, genuinely enjoy each other's company, maintain positive energy, and actively support one another. This dynamic enables remarkable achievements. Maybe someone knows a contact in another tribe, release train, or department who can provide crucial answers and facilitate communication. Communication is absolutely fundamental.

That collaborative spirit is the hallmark of truly effective teams.

Hayley Rodd: Absolutely. We would know it in our day-to-day work, right? If your teams aren't communicating, if they're too overburdened as you said, it's not a good place to start. But if you can get that starting point right, if you can get that communication right, so many things will flow after that.

Andreas Wengenmayer: Absolutely. Looking back at any planning cycle, the real test is: did you plan the right things? You only know at the quarter's end whether you estimated capacity accurately.

Here's the crucial question: How does your organisation respond when goals aren't met? Do stakeholders focus on finding solutions? Do team members feel safe asking probing questions and seeking answers? Or does the blame game begin, searching for scapegoats?

How does your organisation respond when goals aren't met? Do stakeholders focus on finding solutions? Do team members feel safe asking probing questions and seeking answers? Or does the blame game begin, searching for scapegoats?

When you're permitted, encouraged, even, to be genuinely open and honest, you become much better at assessing realistic capacity. What makes stakeholders universally happy is predictability. You want confidence that your plans will actually materialise, that your commitments will be fulfilled.

Success breeds success, creating a positive foundation for the next PI. It's a continuous cycle that can spiral upward toward excellence or downward toward dysfunction.

The startup vs. enterprise spectrum

Hayley Rodd: Let's talk about the two ends of the spectrum. You've got a lot of experience, so I love hearing about this. Small companies will often say, "We're agile, we can pivot quickly, we don't need formal goal setting." Then enterprises are going all out on OKRs, cascading objectives, saying they're aligned because they've got those things in place. Yet both struggle with the same core problem. What's really going on?

Andreas Wengenmayer: You're absolutely right. I've been in agile projects since 2014, 11 years now, and I've seen a lot of companies pre-COVID, post-COVID, different sizes.

Starting with the really small ones, startup companies - what's really astonishing is that some very small startup companies tend to become overly complex, which is amazing. Some want solutions that are way too overblown. Basically, they need a sailing boat, but they're thinking about ordering an aircraft carrier.

Some startups want solutions that are way too overblown. Basically, they need a sailing boat, but they're thinking about ordering an aircraft carrier.

Maybe that's part of startup CEO culture - where everyone's a CEO on LinkedIn, and they think, "We're corporate, we have to be like that." They mostly get to their senses in the end, but small companies tend to be overly complex and overblown when it comes to technology, tooling, and organisation.

On the other end, large corporations sometimes seem to try their best to become truly agile - living the values everywhere. Still, it's a challenge. In most cases, there's some kind of hybrid planning going on. There's still a roadmap, which is good, but at some level, some people still stick to classical approaches, have some waterfall going on in the back.

I personally have never seen, for example, a full SAFe organisation where it's done truly at every level. There's a good balance and it should be healthy, but it all comes down to execution.

I feel like mid-sized companies are often the healthiest when it comes to that.

There's a balance of method and tooling, but you still need a solid understanding of goal setting and tracking. This includes pivoting when goals aren't right and learning from how you did things in the past. The gap between management and teams isn't that huge, and it's easier to bridge.

Avoiding death by KPI

Hayley Rodd: You've touched on so many fundamental things around getting the method and tooling right, but also that cultural aspect. I love the insight around mid-size organisations often striking that balance well. When we're thinking about the enterprise risk - which could be "death by KPI" or OKR, do you agree? Can you paint a picture of what that looks like and how it actually makes teams less focused?

Andreas Wengenmayer: Absolutely. There is such a thing as "death by KPI." KPIs are important to get a clear picture - you do need metrics, and there's merit to it. But as always, it's about choosing the right KPIs, the right metrics.

My favourite example is comparing story points across teams or ARTs. You measure velocity, and I have to repeat again and again: it's only individual to one team. You shouldn't compare it to another team or across tribes or ARTs - that doesn't work because you're creating the wrong incentives.

You see what will happen: "Well, okay, my stakeholders want higher amounts of story points. Let's estimate the stories bigger." Of course, that's a continuous loop, but it doesn't give you anything. Story points as a metric are just guidance for a team to get a better feeling for estimations.

You see what will happen: "Well, okay, my stakeholders want higher amounts of story points. Let's estimate the stories bigger." Of course, that's a continuous loop, but it doesn't give you anything. Story points as a metric are just guidance for a team to get a better feeling for estimations.

You want predictability - you want to meet a certain range. So it's not a great KPI when it comes to monitoring progress across teams. They have better KPIs in place.

Other metrics tend to create what I call bureaucracy. If you spend too much time creating reports, you have less time to create anything of value.

Hayley Rodd: I think there's so much in what you're saying about people being realistic and honest, open to pivoting or changing a goal if it's not the right one. Admitting to that is really difficult because no one wants to admit that what they set out to do is failing. But understanding that failure can sometimes be a benefit - you can learn from that. There's so much in that cultural aspect, right?

Andreas Wengenmayer: Absolutely. Coming back to goals rather than KPIs - KPIs are like being on a boat in your control room. You see what the engine is doing, the temperature - those are KPIs. Goals, on the other hand, are the course that you set.

KPIs are like being on a boat in your control room. You see what the engine is doing, the temperature - those are KPIs. Goals, on the other hand, are the course that you set.

You could be a small company like a startup - you're in a canoe, you're rowing. Or you're a large company - you're like a big freighter. Still, if you don't set the right course, the right goal, you will never reach your destination. Your team can be as proficient and perfectly working as they could be. If the course isn't right, hopefully you have enough provisions on board to survive a long journey.

Where organisations get stuck in goal setting

Hayley Rodd: Where do organisations typically get stuck? Is it defining the goals, communicating the goals, or translating them into action - that execution point you made before?

Andreas Wengenmayer: It could be basically any one of those. If you have a smaller or mid-size company, it's easier to communicate - you don't have to bridge as huge a gap. But still, you have high-level goals that have to be translated into real work. Real value is created in the teams.

If you have a high-level goal that's highly abstract and sounds good on paper - "increase customer satisfaction," "create better products," "make the world a better place" - people still have to understand: What does that mean to my daily work? If I'm a developer, what's my stake in that? How can I contribute?

If you have a high-level goal that's highly abstract and sounds good on paper - "increase customer satisfaction," "create better products," "make the world a better place" - people still have to understand: What does that mean to my daily work? If I'm a developer, what's my stake in that? How can I contribute?

That's when communication and breaking down goals becomes really important. Breaking them down the right way, having them visible and transparent, and creating that feeling of contribution. You make it visible that you're not just working for yourself or your team, but you're really contributing. You understand what you're working on and why you're doing it. Purpose is critical.

Bridging the strategy-to-sprint gap

Hayley Rodd: That's a really good segue into the next question about translating strategic vision into team-level objectives that people can grab onto and execute. Leadership will often say something like "increase customer satisfaction," and teams are left going, "What does that mean for me in my sprint this week?" How does an organisation bridge that gap between the high-level leadership view and what we can do in our sprints as a team?

Andreas Wengenmayer: First of all, you as company management need to take the time. There have been, and still are, a lot of approaches with company values, putting posters on walls, creating marketing. Those are all values - that's what a company is like. Then you link it with your products, services - great services, customer satisfaction. Okay. Then comes the real challenge: we want to succeed and create the next service, software solution, or product.

The goal is clear on a high level, but how do we break it down? That's when the real work comes into play - breaking down the goals into smaller pieces.

It's like building a LEGO space station when I was a kid. You have the picture on the box in the beginning - 'Oh, that's what we're going to build.' Then you have to start putting together all the small pieces. You need a plan, you need the little pictures of the steps. You start with the big picture, then you're breaking it down one piece at a time. You create different parts, and they come together at the end. Same goes for goals.

It's like building a LEGO space station. You have the picture on the box in the beginning - 'Oh, that's what we're going to build.' Then you have to start putting together all the small pieces. You need a plan, you need the little pictures of the steps. You start with the big picture, then you're breaking it down one piece at a time. You create different parts, and they come together at the end. Same goes for goals.

Hayley Rodd: Nice. A colleague of mine often says you eat an elephant one bite at a time - similar thing, right? When you see that big goal, it's really overwhelming. But if you can break it down into those chunks and smaller pieces, it becomes so much more manageable and achievable. People can get behind that vision.

Managing moving targets

Hayley Rodd: In fast-moving environments, goals often shift. We're agile, we're always moving. How do you help teams stay connected to a moving target without either ignoring changes or constantly thrashing around?

Andreas Wengenmayer: Back in the nineties and early 2000s, there was a computer game that wasted a lot of time in offices where you were shooting at geese in Scottish Highlands. It was a big phenomenon because people were trying to get the next high score.

If you think of moving targets, it's a bit like that. Imagine you're doing your work - whether you're a hunter or developer doesn't matter - but you approach, you take aim, and the geese keep flying up. You miss the target. Same thing if you have moving goals.

It's harder to aim and approach them right. What you should avoid as a company or someone in charge is constant interference. Stick to your goals or objectives that were agreed upon during PI planning. Don't change them midterm during a PI.

What you should avoid as a company or someone in charge is constant interference. Stick to your goals or objectives that were agreed upon during PI planning. Don't change them midterm during a PI.

That doesn't mean you can't learn from mistakes or wrong goals. You can adjust them, but you have to adjust them in the right place and time, which is during planning. Of course, if something security-related comes up, you have to act, but it has to be agreed upon, and you still have to communicate it and create understanding.

Keeping goals visible and actionable

Hayley Rodd: Even when goals are well-defined, keeping them visible and actionable throughout a PI is tough. What practices or tools have you found most effective for maintaining connection between daily work and high-level strategic objectives?

Andreas Wengenmayer: Good question. Having the goals present at all times helps a lot. If you just meet for planning, have your goals set, and never look back during the PI, it doesn't do you any good.

That could be a piece of paper on the wall like we had back in the day - and still could be if you're working in the office. Also, choose the right tools to track the goals and create acceptance for tools. Really use them. Look into them - whether it's an OKR tool or some other solution, even PI objectives. Are we still on track?

What really helps is if it's not static but shows progress, and especially shows the link of what you're contributing - like what you achieved in your last sprint and how it plays into the objectives or goals, progress moving ahead. There's always a good feeling - everybody loves a green bar moving ahead or a checklist.

What really helps is if your tool is not static but shows progress, and especially shows the link of what you're contributing - like what you achieved in your last sprint and how it plays into the objectives or goals, progress moving ahead. There's always a good feeling - everybody loves a green bar moving ahead or a checklist.

It helps keep the vision and goals present.

Hayley Rodd: When I was a teenager in my final year of high school here in Australia, I wanted a specific score on my final exams. I had a big poster in front of my desk that I sat at for hours every day studying. Looking back, I didn't know what I was doing - I just wanted to visualise my goal, and I didn't know the psychology behind it. But I'm happy to report I got that mark and above.

I think it was as you were saying - that constant reminder, that piece of paper worked for me. In organisations, we're looking for something a bit more complex sometimes, but I like your "keep it simple" advice. It doesn't always have to be super complex. It can just be a checklist, progress bar, or piece of paper - something that helps you feel connected to the goal and reminds you of it often.

When good work doesn't align with goals

Hayley Rodd: Have you seen situations where teams were delivering lots of work - good work, but it wasn't clearly contributing to company goals? What tends to cause that disconnect?

Andreas Wengenmayer: Yeah, that happens quite a bit. I can think of one example with very technical teams, like in semiconductors. Very smart people - everyone has a PhD in physics, material science. Awesome, smart people who tend to love their job. They're awesome, but they're also perfectionists who can still improve things and want to make them even better.

If you're in the business of producing machines used to produce semiconductors, for example, it's a complex task with a complex supply chain or value chain. You're creating lithography machines to create wafers used by other companies, and in the end, you have a customer planning the release of a new phone.

Your customer waits, the end customer waits, and you have to deliver on time. Sometimes this creates a challenge because teams still want to improve and make it even better. That's when economics come into play - the view of the big picture. You still have to communicate it. You shouldn't discourage such a great team, but you need to get the bigger perspective back to the teams and create acceptance instead of saying, "Hey, stop what you're doing, it's good enough." You don't want that. It all comes back to transparency and communication.

On the other spectrum, what you sometimes have is just too much workload on teams. Time for planning gets cut short, and if you don't take enough time to plan well, no wonder the results don't work out. It's just a lot of busy work - a lot of things getting done, but not necessarily the right things at the right time.

On the other spectrum, what you sometimes have is just too much workload on teams. Time for planning gets cut short, and if you don't take enough time to plan well, no wonder the results don't work out. It's just a lot of busy work - a lot of things getting done, but not necessarily the right things at the right time.

Hayley Rodd: If you don't do that planning at the start, you're setting yourself up for misalignments. If you're not communicating that plan regularly, you're setting yourself up for that busy work and people getting distracted. It's just so common. That planning part is so fundamental to getting it right.

One piece of advice for frustrated leaders

Hayley Rodd: We're on the home stretch now. If you could give one piece of advice to an engineering or product leader who's been frustrated because their teams seem to be going through the motions of PI planning or quarterly planning without real buy-in, what would it be?

Andreas Wengenmayer: I can resonate with that so well, and many can. I'd say: take the time to find out what's really going on. Investigate the root cause. It's like if you have a house and you're trying to fix a crack in the wall - you can look at the crack and do some superficial fixing or use a thick layer of paint, but you still have to find out what's causing that issue. Maybe something deeper.

You mentioned the five whys - that can be one way, but you have to have some understanding of the right way to approach people. You don't want to put anyone on the spot. Looking for a scapegoat doesn't help anybody.

We need to look at what's behind it, what's causing it. It all comes back to investing enough time for planning, but doing it with purpose. Not doing the whole planning like theatre, where everybody acts their part - that doesn't do you any good.

It all comes back to investing enough time for planning, but doing it with purpose. Not doing the whole planning like theatre, where everybody acts their part - that doesn't do you any good.

People have to understand why they're doing it. There has to be purpose and understanding - enough time, no distractions, and a positive atmosphere where everybody can contribute and be open.

You don't want people saying nothing because they don't dare to criticise or say no.

The connection between goal clarity and team motivation

Hayley Rodd: What's one thing you wish more organisations understood about the connection between goal clarity and team motivation?

Andreas Wengenmayer: We could get back to the boats we mentioned before. You want to arrive at your destination. If you're not clear about the destination, or maybe some people in your rowing boat don't want to go there, they might not join the rowing. If your crew is not invested, it will take you longer to reach a destination, or you won't get there as well.

It's the same thing. Motivation is key, and I don't talk about superficial motivation that just annoys everybody. Motivation is a positive environment where people rely on each other. They really like spending time with those people.

"Hey, I really like to go to lunch with you and talk to you" - not "I'd rather be home and not talk to anybody." You're not annoyed if your teammate asks you a question; you're happy to help. You're feeling safe that when you have a problem or question, you will get help.

That creates the right kind of motivation - that positive environment, and that can make a lot of things happen. It comes back to openness and transparency, not as buzzwords, but to get the clear picture. As a stakeholder, you get the correct current state because you get true answers.

I've seen strange situations in major corporations where people really didn't report what they were working on or show the right results. I've seen complete shadow Jira environments - one for internal use and one for external use with customers. There can be huge misalignments because people didn't dare to show real progress. In the long term, it will backfire. If you don't have trust in your environment, in your company, you will have a hard time.

I've seen strange situations in major corporations where people really didn't report what they were working on or show the right results. I've seen complete shadow Jira environments - one for internal use and one for external use with customers. There can be huge misalignments because people didn't dare to show real progress. In the long term, it will backfire. If you don't have trust in your environment, in your company, you will have a hard time.

Wrapping up

Hayley Rodd: There are so many key themes coming up throughout our conversation. You've talked about ongoing communication across teams, really planning with purpose, getting that context and buy-in to help with motivation, and allowing for radical candour - being really open if something's not working and being okay to call it out. So many cultural and communication elements are critical to the success of quarterly planning, PI planning, and organisations generally. Great takeaways.

We're going to end it there, but I want to end with a teaser for our interactive webinar that you and I are doing together on September 4th, which dives deeper and shows how to operationalise the ideas we've chatted about here using Easy Agile Programs and linking back to the fundamental services that catworkx provides organisations.

Andreas, it's been super wonderful to chat with you. I look forward to our webinar coming up on September 4th.

Andreas Wengenmayer: Thank you so much for having me. Looking forward to September 4th and seeing you again, talking more about tooling, boats, duck hunt, and anything in between.

Ready to transform your strategic planning?

The conversation doesn't end here. Andreas and Hayley hosted an interactive webinar where they showed how you can put these strategic alignment concepts into practice.

They spoke about:

• Practical techniques for breaking down strategic goals into actionable team objectives
• How to maintain goal visibility throughout your PI cycles
• Real-world examples of successful alignment transformations

Watch the webinar recording here →

"I loved having the space to talk about common interests - all things technical documentation & information architecture" - Henri Seymour

On this episode of The Easy Agile Podcast, tune in to hear Henri Seymour - Developer at Easy Agile speak with Matt Reiner - Customer Advocate at K15t.

Henri & Matt are talking all things technical documentation (we promise this episode is way more interesting than it sounds! 😉)

✏️ Considering technical documentation as a product
✏️ The value of well written documentation
✏️ Why you should be digitally decluttering often
✏️ Information architecture

So many golden nuggets in this episode!

Be sure to subscribe, enjoy the episode 🎧

Transcript

Henri Seymour:

Hi, everyone. This is the Easy Agile Podcast. We've got an episode today with Matt Reiner. I'm your host for today, Henri Seymour, developer at Easy Agile. And just before we start the podcast, I'd like to acknowledge the traditional Australians of the land on which I'm recording today, the Watiwati people of the Dharawal nation. Pay respect to elders past, present, and emerging, and extend that respect to any Aboriginal or Torres Strait Islander people listening to this episode.

Matt is an experienced content strategist with a history of working in the computer software industry, skilled in agile scrum framework, related tools, communication, technical writing, video production, customer interaction, strategic planning. And he's here today to talk with us about writing and specifically technical writing and documentation. Hi, Matt.

Matt Reiner:

Hi. It's great to be here. Yeah, I'm Matt. I'm into all sorts of content things. And one of those is technical writing, which is, I think more interesting than it sounds. I guess you'll have to decide by the end of the podcast, if you think so.

Henri Seymour:

Technical documentation experts. So when you talk about technical documentation specifically, what do you mean by that?

Matt Reiner:

Well, I feel like that term is actually in the middle of a big change right now. In the past, technical documentation was very strictly like, "Okay, we're a team, we're making a thing, a product." Maybe it's an app, maybe it's, I don't know, a go-kart and we need to have a user manual for that. Technical documentation was someone sitting down and writing down, "Okay, here are all the knobs and switches and here's what they do. Here are all the features. Here's maybe why you would use them."

So putting together that user guide, which traditionally was printed material that you would get with the product. But it's become a lot more over time, partially with the internet, because we can just constantly iterate on content like many of us do with the products that our teams make. And then also we are seeing it in new forms. Maybe it's not a printed piece, in fact, most people do not want printed technical documentation anymore, they want it online. Or even better, they want it right in context in your app when they're using it, they can just get the info they need, and then get on with it.

That's what technical documentation is. It's supposed to be there to help you do the thing that you really care about and then get out of the way so that you can do it.

Henri Seymour:

Do you have a description of why good technical documentation? Not just having it, but having it at a good quality in a way that really helps your users, is so important to product users.

Matt Reiner:

Well, I suppose we all find those points in our day or in our journey that we find ourselves in where we want to accomplish something, but we don't know how to do it. So a lot of us have really gotten very used to jumping on Google and saying, "Okay, here's this thing I want to do, how do I do it?" And good technical documentation is there with the answer you need, the explanation you need. Because really ultimately all of us are smart people who should be empowered to do the thing we're passionate about.

And technical writers and communicators who are really all members of our team. People who sit down to create good technical documentation uses few words as possible to get a person on the way they're going. And that's like, when it happens its just like, "Glorious," not to the user. They don't even know that it happened, they didn't even know that they read your writing. But to the writer, it's like, "Yeah, I did it, I did it. They don't even care what I did, but I did it." And now they're doing the thing that really matters.

Henri Seymour:

That's great understanding one of the major differences of like, I've written something and I don't want my user to be spending time on it. I want as little time spent reading this as possible.

Matt Reiner:

Yeah, yeah, yeah. You can have great pride in your work, but one of those metrics that a lot of people look at for websites is time spent on page. So sometimes you can fool yourself into thinking, "Oh wow, they spent 10 minutes on my page. That means my documentation's really good." But also that might mean that it's not very good and they're having to reread it over and over again. So the true metric is, did they get to the thing they really cared about? And unfortunately, it's hard to measure.

Henri Seymour:

You mentioned now that with the advent of the internet and giving you the opportunity to iterate on those docs in a way that you wouldn't be able to with printed documentation. That iterative thing brings the agile process of iterate on something that you already put out and improve it in the same way that as a developer I do for products. Can you tell us more about that iterative agile sort of process?

Matt Reiner:

Oh yeah. Yeah, it's so true. Documentation used to be back in the waterfall standard, more typical product project management days, documentation was a major part of it. You'd start this project by writing these massive documents of, "Here's what we're going to set out to do. And here's all the considerations, and here's how everything's going to connect up." And that did work really well for a lot of hardware. Which was the thing that we made for a long time. Just everything that humankind made was hardware often, as groups anyway.

And then all of a sudden this whole software thing comes along and we're trying to build that like it's a physical thing. And we get to the end of this two-year software project and people are like, "Yeah, that's not the thing that I wanted." But we're like, "Oh, but we go back to the beginning and look at that documentation, and that's what you said you wanted." But now with the internet and with just agile development, we really need to move away from this place where we start with a pile of documents. And then we develop another pile of documents as our, I don't know, development guidelines.

And then our test plans, and then finally we end up with user documentation. Instead, these days, documentation should really just grow from a very small piece of content throughout that whole agile development cycle into that final user documentation. Because it doesn't matter what we set out to make, it matters what we make. Nobody he wants to read about what we thought we would make, that's straight up fiction. And it's probably not an interesting read. It's really that final user guide that comes out of the agile process, but that's a big change, but it's a good one.

Henri Seymour:

I love that idea of just like, this is gradually growing. There is no specific start block and end block. It's a process. And you mentioned the opportunity to iterate on those documents. Do you have any advice for after you've published digitally your technical documentation from iterating on what you've already got there, improving that over time?

Matt Reiner:

Oh yeah. I know every agile framework is different, but they all have that feedback phase, where... And really that's throughout the whole process, but we do need to dedicate some time. So, there's a lot of different things we can look at. For example, I don't want to say basic, a standard one that we should be looking at is, you should have a help center, where you can implement something like Google Analytics so you can see just, what are people looking at? How long are they looking at it?

Another really good one is, you have to set it up separately in Google Analytics. What are people searching for on your site? You can also use Google... used to be Webmaster Tools. I think it's called Site Tools now, but you can see what were people searching for on Google before they came to your pages. That's all really, really valuable stuff. Then you can get more advanced. You can look at pointer tracking, apps that you can embed on there, which you get some pretty wild stuff.

But then you also, you want to consider having a forum at the bottom of each page like, "Was this helpful? Was it not helpful? Oh, it wasn't helpful? Tell me why. Oh, it was helpful? Tell me why." Just like a YouTube creator, they look for that feedback. That feedback is essential, the thumbs up. In fact, it's very controversial, YouTube just announced that they're going to hide the thumbs down numbers, but a lot of creators are like, "No, no, no don't do that because that communicates the value of this video that is out there."

So there's a lot of those signals. And then there's just really soft signals that, it's hard to know if people are using the content or not. Because you may never hear. Especially, if it is one of those things that they just get in and get out, you're not going to hear anything about that. But the feedback phase, it's really great to... Anytime you're getting feedback on your product that you're making, try to get your documentation out there as well. Because that's the time where people are open to exploring your product and giving feedback.

So why not explore that same documentation, the related documentation to see, "Okay, is this actually helping these people do the thing that they want to do? Or should we improve it just like we do with the product?"

Henri Seymour:

No, that's a really good, comparing the, we've just released a product. Give us feedback with doing the same thing with the documentation. Because that's when it's going to reach its peak use before everyone's got the hang of it. We've just done this feature release, let us know how you go using it, and the documentation is in a sense part of it, especially for more complex products.

Matt Reiner:

Exactly.

Henri Seymour:

Do you have any background in the customer support side of things? We do customer support in-house as well as their documentation. So we're trying to improve the documentation to lower the support load on our team. Do you have any background in that... Can you solve it?

Matt Reiner:

Yeah. Well, yes and no. It's interesting. I work at K15t now, I used to be a customer of K15t's, so that's actually how I met the team. And that was also how I met documentation in the first place. At my last job, they brought me in to administrate this system called Jira. And I was like, "I don't know what that is." I told them, "I thought I could do it." And I figured it out, it was this little thing called Jira On-Demand, which is now Jira Cloud. And I introduced Confluence On-Demand to the company as well. And wow, I broke Jira a lot of times.

Luckily it wasn't like mission critical at the time, we were still really figuring it out. But it was through Atlassian's documentation on Jira that I really learned like, "Wow, there is tremendous value to this content here." And then I discovered, "Okay, how is Atlassian creating their documentation? Oh, they're doing it in Confluence. They're writing it in Confluence. They're using these apps from K15t." And so I started using those apps, and then I talked a lot to K15t customer support, just questions and how do I get this started?

And we also do our support in-house, so it's really great. So maybe as a customer, I overused it, I don't know. I should ask some of my colleagues if they got sick of me. But the benefit was very clear because they would send me, "Oh, here's documentation on this. And here's the answer to this question or here are the considerations you should keep in mind." And actually several of our teams now, we're really looking at, especially, for those features that are very robust, people have questions.

So it's like, how can we enable them to help them help themselves? And putting those resources out there is one thing, making sure that Google can find them, well, is another. But that is a really important thing, especially, since as a product team, when your user base grows, so does your need for support. It's just... I don't want to say it's exponential, but it's in line with each other. And so, one of the ways you can mitigate that is, making sure you have good design so that your product is easy to use. And then another is you need to have good content all around that entire experience so that you don't have to keep hiring more and more support people.

Or your support people can specialize and really focus on those deep entrenched issues, and then the documentation should help with the rest. But the secret sauce there is tricky. It's hard to write the perfect content to deflect the cases. That's everybody's dream.

Henri Seymour:

Even if it is just not all of them, but some of the common use cases start to get deflected away from support because people can self service. It does make a difference. And I really understand the idea of Jira documentation as well. Easy Agile works on Jira and it's... Jira is an incredibly complicated product at this point, and I imagine it probably was also complicated when it was Jira On-Demand. Because it's so complicated and so detailed, there's no way to make that easy to understand for a user without that documentation. There's no getting around that one.

Matt Reiner:

Yeah. I think there should be a club for the people who have broken workflows too many times in Jira. But yeah, I mean the documentation saved me many times and I would have to put out a... Well, it was a HipChat message at the time. May it rest in peace and I'd have to say, "I broke Jira, give me a minute. I got to go read something." Not the way you want to learn Jira, but it's an option.

Henri Seymour:

It is. Sometimes you learn things by breaking things. That's-

Matt Reiner:

That's right.

Henri Seymour:

Really seems like my experience in software so far. You try to break the things that people aren't currently using and that's about all you can do.

Matt Reiner:

Exactly.

Henri Seymour:

So K15t has recently published Rock the Docs. Can you tell us a bit more about this project?

Matt Reiner:

Yeah. Rock the Docs, actually, it came out of a lot of that information that I got from K15t. Customer support, I got from K15t documentation, I got from Atlassian documentation. And then some of the stuff I figured out on my own, or some of my colleagues at K15t did. Essentially like, what are the best practices for creating really good content in Confluence? And it really started with a collection of guides on how to create technical documentation content. It's geared toward like making a public help center, but really it's for any kind of content that you want to be like evergreen, longstanding content to be able to help people.

So we initially talked about all sorts of things like structuring your content, content reuse, managing multiple languages, which can be tricky in Confluence. Collaboration, publishing your content outside of Confluence in one way or another, managing versions of that content. So, that's the start of it. And then we saw a lot of positive response with that and we had more general questions like, "Okay, but what are the best ways to get feedback in Confluence?" Or, "How do I make a template or a good template or how do I make a good diagram in Confluence?"

And so we've grown that content to focus on just all sorts of general Confluence things. Because we found that there's a lot of information out there on how to do something. Atlassian documentation really helpful, but there wasn't as much, I'm like, "Why would you do it? And why would you do it this specific way?" And we've been working with Confluence for over 10 years now. Like I said, I've been with Confluence since the crashy early cloud days. It's grown up so fast, it's beautiful.

But we just know we've done a lot of stuff with Confluence, so it's been a real privilege to share that both in like these written guides. And then actually recently we've started publishing a series to our YouTube channel as well, all about Confluence best practices.

Henri Seymour:

That's great. It's real interesting to hear how that started as a smaller project than it turned out to be, because you could see the value in it and the use in it. We've discussed Confluence a few times now and K15t builds apps that use Confluence as a documentation source. Can you tell us more about what makes Confluence useful for building technical documentation? What sort of tools and approaches that make it useful in this context?

Matt Reiner:

Yeah. Confluence is by nature open, which is not the way technical writing tools are built. In fact, I remember the first time I went to a technical writing conference and someone asked me, "Oh, what tool do you use?" Which is like, what technical communications people talk about, because we're all nerds in that way. And I was like, "Oh, I'm doing it in Confluence." And they didn't really want to talk to me after that because they didn't think I was a serious tech writer. And I was like, "Oh no, no, no, no, this is all happening."

At that point, Rock the Docs didn't exist. So I couldn't be like, "Go over there and see how it works." But the biggest difference is most tech writing tools are just totally locked down. You have two licenses for your two people who are trained professional tech graders, and then everybody else, there's no access. You don't touch it. Maybe your tech writers will send you a PDF and you have to go through the God awful process of marking up a PDF to tell them like what to correct. Or, I've heard of teams printing out the content and people penciling in what needs to be changed.

The review processes are just out of this world insane. And those tools don't fit terribly well with agile processes because it's like, you build the thing over here, and then here's the two tech writers over here in their separate tool. And at some point we'll be like, "Okay, this thing's done. Would you write about it?" So with Confluence, the benefit of using Confluence is, it's accessible to everyone on the team and even people outside the team. And that's incredibly by an official because we've seen with agile, but we're also seeing in this technical communication and in information design field, that teams are less and less looking for those specialized individuals who are trained tech writers.

Which that's an oxymoron because half of us, we don't have degrees in tech writing, we fell into it for one reason or another. But now teams are starting to see, "Hey, I can be a code developer and an information developer. I might not write the final piece of written content that is seen by our customers, but I might write the first draft." Confluence really opens that up for everyone. And especially with like at mentioning and inline comments, review processes are just so fast.

Actually, the reason that I switched to Confluence at my last job, was my product manager threatened me and said, "I will not mark up another PDF. Go and find a good tool that we all want to work in." And that's where we landed on Confluence. It's about bringing the whole team into the writing process instead of having it be this separate thing. Because when it's a separate thing, we lose track of it. And content, we forget how important it is to our product, to the customer life cycle, to... God bless customer support, who really, really need that content to be good and accurate.

And it needs to be seen by the real experts who validate, "Yeah, okay, this is correct. This will actually show people how our product works." And Confluence is like the heart of that.

Henri Seymour:

No, it's great to hear how that all comes together to build the documentation as a team. Can you speak more to the different roles in, specifically in software development and the different roles you're looking to get involved in your documentation process? We are working on building our specific app teams here at Easy Agile as we're growing at the moment.

Matt Reiner:

Yeah. That's such a good question. Well, what-

Henri Seymour:

And how do you incorporate... Sorry, this is more specific to my question. How do you incorporate that technical writing process as part of the work of an agile software development team?

Matt Reiner:

Well, first, it starts by rethinking priorities because most teams are like, "Documentation down here, testing and then everything else above." So generally, those two things should be moved up. And actually, the content around our product is... I don't want to sound over traumatic, but if we don't have information, we don't have a product. I don't care how much code you write. If we're not explaining it to people, if we don't have good UI text, if we don't have good in-app help, it doesn't exist. It's not a useful tool, it's just a set of mathematics that humans can't interact with.

So content is essential, so it's really important that we elevate it to the position where everyone on the team recognizes that the content experience that our users have is the product experience they have. So it needs to be part of the product development process. So then the next step, which I know you're talking about team structure, but the next step is really everyone on the team needs to know they're a writer, and they're a good writer. And that's important because a lot of people have never heard that. They've never heard that they're a good writer, and they probably have never heard that they're a writer.

I remember going through university, my writing classes were the things that I didn't pay attention to. I was doing mathematics, and Java programming, and statistics. Even that seemed more important to me, not the writing classes. And then sure enough, it turns out everyone has to write. We all write. So knowing that that is a role that everyone fills is really important. And then when it comes to actually team structure, you need to have individuals who are willing to cross the streams, so to speak. If you're bringing in someone who's focusing on test engineering, they need to realize that the test plans they're writing are very similar to a lot of user documentation that needs to be written.

They're writing task topics, or task instructions, do this, do this, do this over and over again. That's documentation. They could be contributing in that way. Engineers, as I mentioned, they could be drafting the first copy of a lot of what are called concept topics. So areas of documentation where you explain concepts, because they already know what those concepts are. In fact, if you look at the root of a lot of agile development teams, they're using epics and user stories and acceptance criteria. And all those map perfectly into the documentation you needed to create for that new feature you're working on or feature you're improving.

So really, it's essential to have everybody recognize, we are all already creating documentation, so we can contribute. And then of course, you really do want to have at least one probably native English speaker. Maybe not native, but someone who feels confident in their English or whatever language you're authoring in. English is typically the cheapest one to translate to other languages, so that's what people go for often. But that person's the person who takes everything everybody's written, gets it to the right style and tone. And then gets it out there. That's what we are seeing be successful.

Like our teams right now, we don't have any legit tech writers. We have product managers writing. We have product marketers writing. We have engineers writing. Some of the best documentation I've ever read was from one of our German-speaking engineers. I was like, "Peter, this is an amazing guide. You got to get out of this Java and get into English, man. It's great. It's great." So he's done a few, which I really love. But yeah, it's about jumping out of your typical roles and realizing, we're all documenting this stuff, anyway.

Henri Seymour:

I love the focus, especially with your German-speaking colleague. The focus on, it's not just that you must write the documentation because you know how the product works and we need that written down. It's, you are capable of writing the documentation, you can do this. You have that added barrier of safety with somebody who's got the language proficiency that they're going to massage it and edit it at the end.

So, before it gets anywhere, anything that you do is going to get filtered out if it's not working. But you don't need a specific tech-writing background to write the docs.

Matt Reiner:

No, absolutely not. In fact, there's an entire community of what... They call themselves documentarians called Write the Docs. And that whole community, that whole group is focused on, it doesn't matter what you do, it matters that you care about writing the docs, contributing to the content. And that's been a big shift, I think in the industry, where people thought we're separate. But now it's like, "No, no, no, we are all able to do this." And once we can respect the contributions that each of us can make.

And then also, I have that protection of somebody else is going to have their eyes on this, which even my writing, I'm like, "I don't like to send it out until someone else has seen it." Because I make spelling mistakes and typos all the time. I really want to have another colleague look at it. Even if they're not native English speakers, because they catch my typos pretty often. That feeling of togetherness, it's the same way that we feel when we ship out a project or a product.

Whether you did the testing for it, or you wrote the code for it, or you did the product marketing for it. It's like, "It's our baby. Let's send it out and see what happens." Content's the same way.

Henri Seymour:

Yeah, part of my daily role and [inaudible 00:28:03]... We don't have QA team separate from developers. Our developers also review our code and it's that sense of, "I wrote this thing, but I have one or two other people who've refined it, who've made sure that it's good enough quality. They've got that fresh eye, so they'll see the spelling mistakes, they'll see the minor little errors that I've just been looking at it too long to notice anymore."

I found the documentation writing process has some parallels in there like, "Here's my thing. I'd like some feedback on it before it goes out into the real world."

Matt Reiner:

Yeah.

Henri Seymour:

That's great.

Matt Reiner:

Yeah, absolutely. Yeah.

Henri Seymour:

All right. Can you talk a bit about the difference between the customer-facing documentation that we've mostly discussed so far and internal documentation?

Matt Reiner:

Yeah. There are some differences and there are some major similarities. So this very... It sounds very technical and ugly. The term information architecture, it's really important with any kind of content, internally and externally. And really that's like, if you're a developer you're familiar with XML, you're familiar with structuring things in that way. Our content needs to work the same way. And that goes for internal and external documentation. So, many of the things that they use, writers, when they write a page or an article in the newspaper, they'll use that Pyramid approach, where they put the broad bits of information at the top. And then they slowly focus in on the topic and give more and more information about it.

But you want to make sure that if somebody only reads the first paragraph, they're getting a rough idea of what the information is. And that's really important for successful Confluence pages and spaces. People should be able to start at the top level of the space, understand what the space is about, and then be able to navigate down into the thing that they really want to learn about into the page itself. Which should then be using headings and subheadings and bullet points to get, again, just disseminate that information and break it down. Because everybody skims.

We need our content to be skimmable, our spaces need to be skimmable. And that kind of content also makes Confluence search happy, especially the new Confluence Cloud search, which has been greatly improved. There's a whole new elastic search base to that that's being optimized. But it's happy, it's just like with Google when we structure our content like that. So when you have a page that is just a wall of text, no headings, you're not breaking it up into pages or even spaces, nobody's going to be happy with that.

The bots aren't going to be happy with it, the people reading aren't going to be happy with it. So it takes a bit of work to structure, break up the structure of our content. It's probably all good as long as it's up-to-date, but it's really essential that we think about, how do we structure that in Confluence so that people can find it and people can skim it? And that is what seems to plague a lot of internal Confluence instances, because a lot of... Maybe the team isn't so focused on that.

It's like, "Oh, our external help center that's come coming from this space over here, that's fine. Our team space, hot mess, total tire fire." And nobody cares because they think they know where everything is. But then you start to think about, "Okay, but what about the new team member? How do they find something?" Or, "What about the team member who's been away for Paternity leave for six weeks? Are they going to remember where everything is or know where all the new stuff is?

What about folks with disabilities? Is it going to be much harder for them to navigate to the information they need? Because they're working with a screen reader and they're trying to go through a wall of text. They need headings, a screen reader relies on those headings and titles." So there's just so many considerations that really leadership of companies needs to understand, just because you have a process to do something or the information is somewhere, doesn't mean you don't have a major information problem. And maintaining all of your content in Confluence and then maintaining it well.

That is what enables people to avoid the frustrations of searching for information, losing information, having to relearn or rewrite information. I have worked at too many companies that just information sieves everywhere. I don't even want to call them silos because nobody knows where stuff is anymore either. That's what Confluence brings to things, and that's what matters with internal content pretty much as well as external.

Henri Seymour:

That's a great perspective on it. And I can see the silos, it's a really more... Just a one big pile, you can't find anything. I've been-

Matt Reiner:

Exactly.

Henri Seymour:

... at Easy Agile for more than half of its life now and I've got that sense of like, "Oh, I know I wrote this down somewhere. I know I've seen this written down somewhere." And we are making a habit, especially as we're hiring more and more people. Every time somebody's going through onboarding, they're going to be looking at all of this documentation with no previous background on it. And we want to hear their feedback on it specifically. Because if it works for them, then that's the documentation that we need for them and for everyone after them, and for everyone who's already here.

Especially, I've been at Easy Agile for almost three years now, and I've seen it grow from eight people to now we're up to high 20s, I think. We're going to cross over into the 30s by the end of the year.

Matt Reiner:

Wow.

Henri Seymour:

The growth of information that we have in our internal documentation, and I'm sure it would parallel the growth of the product documentation for a product that's been expanding for three to five years. How do you manage the documentation and the Confluence spaces as the team and the company grow and you just develop more and more pages out of it?

Matt Reiner:

That is the question since the dawn of the universe or at least the dawn of Confluence, which, what's the difference? The biggest thing is team responsibility, so knowing this is our space, this is our content. And not like in a territorial way, but this is our responsibility. Much the way we should think about our planet, we should also think about our content, keeping it groomed and taken care of, and up-to-date and accurate. And then as things change.

For example, we have a product called Scroll Viewport, which is actually what enables you to publish content from Confluence to a public health center, which is really, really cool. So with that, we had a server and data center version. We've had that for quite some time. That's what I was a user of. And then we set off to develop a cloud version, and cloud requires a whole bunch of new infrastructure, which is a lot of fun and very challenging, but it's a totally different beast.

It's not like you can just lift the server code and just drop it into cloud, which is what as a user I asked them to do for years, "why isn't this on cloud?" Now I know why. So we created a new team that started off this Scroll Viewport on cloud effort. And it was just a very scrappy project at first. And I remember the first page we got up there, it's like, "Whoa, look at this page we published." And then it progressed from there. But then at some point, we needed to bring the two teams back together. And what we could have just said, "Oh, this old Viewport space, whatever. We're just going to leave it there and then just go on with the new one."

But instead the team took time and brought the two spaces together and really went through the old content in the Viewport Server and data center space to say, "Is this all still relevant? Do we still need this?" So it's been reordered in such an amazing way. Several of our teams have gotten really good at making these spaces so that I can come in. Because I work with all of our teams, just get in and find what I need, even though I'm not working their day-to-day. I'm just so glad, I'm so proud of the team for not just letting that space languish somewhere or being afraid to delete or archive content, which a lot of people are.

It's like, "No, what if we lose something?" It's like, "No, no, no, we've moved past this. We really do need to delete it." So that's the kind of attitude it takes is, our teams to split and expand and grow, and we need conscious of that content. Because again, think of the new person, think of the person who's learning something new. Think of the person who maybe does have disabilities and is trying to get the content they need. They just don't have the background that you do. Having been with the company for half its life, you know how to dig through the thought pile to pull out just the thing you want, but they don't.

Henri Seymour:

Yeah, and I don't want to be the person that they have to ask every time they need information, "Hey, can you find this for me?" No, no. I want to build a system that means that I don't have to answer the same questions all the time. That's one of the reasons I've been doing internal documentation so much since [inaudible 00:37:36]. I've answered this question once, that will do.

Matt Reiner:

Yes. That's a really good way to motivate any contributors to documentation. "Hey, you know how you wrote that piece of our app that one time and then everybody's asked you about how it works ever since? Just document it once and I promise you can never answer it again." That's good motivation right there.

Henri Seymour:

It is. As well, we've got a team on support models, so I'm working on the store maps and personas, product development team. And that's the same team that gets all of the support requests about story maps and personas. So yeah, the better we make the product, the better we make the documentation, the less of our time every morning we spend doing that. And the more we can get back to our regular jobs.

Matt Reiner:

Exactly.

Henri Seymour:

It's been great for helping us keep in contact with the customers and what they're doing and what information they need when they're using our product. You mentioned that like it's necessary, it's valuable to be deleting an archive-based stuff, pages in Confluence from time to time. When you're looking at a page and wondering whether or not it's time to go, what sort of questions are you asking yourself?

Matt Reiner:

Well, a great one is like, look at the last modified date on that page. That's general a pretty good sign of like, "Are people even looking at it?" In fact, if you're on cloud premium and above, you can look at some great metrics on every page to see like who's looking at this thing? Is this valuable? What are the views like? Just the same way that you would look at your external website to see if your content is valuable or effective. But typically, we have a lot of debris left over from product development or team activities.

Like if you're in marketing and you have a campaign from three years ago, do you really need all of those detailed pages? Maybe keep the overall campaign page, maybe that's useful, but do you really need everything? If you're into testing, do you really need every test plan you ever created? If you're in the legal team, do you really want your legal terms from 10 years ago? Maybe, maybe, I'm not in legal. But often we have this fear of, it's like fear of missing content.

It's like, "Oh no, if I get rid of that, then I won't have it." But information, just like language, just like the way we think, just like the way our teams grow, it changes. And so we need to be aware of that. As we are changing as a team, you should expect our content to change. And part of that is shedding that old stuff. So it's always worth it, like if you're questioning it, ask another subject matter expert and be like, "Hey, I'm pretty sure we don't need this anymore, or we should revise this. What do you think?" But if nobody has any qualms, you should probably delete it.

Henri Seymour:

No, that's great. I am a big fan of decluttering, even digital decluttering. It's, I want people to find stuff and the less pile there is, the easier it's going to be.

Matt Reiner:

Yes. Because somehow bad information is less helpful than no information.

Henri Seymour:

Yes. It's like coming across a question and they're like, "Oh, I tried doing it this way." I'm like, "Oh, that way doesn't work anymore. You're going to have to do... Where did you find that written down? I'll go update out." It's-

Matt Reiner:

Yeah.

Henri Seymour:

... new people doing stuff. The best way to understand where your documentation is falling over. It's the same as you're never going to understand how your product documentation and that your product itself is failing your users until they come to you and tell you, "Why can't I do this thing?"

Matt Reiner:

Yeah. Yeah. In fact that that power of bringing in someone new on your team is so amazing. And it's almost hard to impart like first day of onboarding like, "You have fresh eyes, please use them. This is called an inline comment, please put it everywhere." I remember going through our human resources employee handbook, which we had just created not too long before I joined. And I remember them telling me, "If there's any questions, at mentioned us." And I was really afraid to do that. But we corrected a lot of things.

For example, we mentioned do these things on... What was it called after HipChat? The product that lived and died so quickly.

Henri Seymour:

I think I missed that one.

Matt Reiner:

Oh, the one that Atlassian made and then they sold it to Slack.

Henri Seymour:

Now, where do I even start on that?

Matt Reiner:

How am I... It was a great app, I really liked it. But we mentioned in the employee handbook to use that. And I'm like, "Oh, I think we're using Slack now, we should update this content." That's stuff that HR is never going to go through and catch, but your new employees can do that. New people are the best way to tell you if your processes are bad, if your content is better. Maybe not bad, but they're bringing in something new. That's why we added them to the team. And they should not be afraid from day one to ask questions, or poke holes in our already messed up or failing process.

Henri Seymour:

Yeah. And I can really see the benefit of the tools in Confluence, like that inline comment. Even if you don't know how you need that page updated or what the new version's supposed to be. It's just coming in fresh, you can go, "Oh, this is weird, or incomplete, or it might be wrong." It's just a little comment. You don't have to change it yourself, just say something. Here's a way to speak up without changing it yourself. And somebody who does know is going to be able to change it for you.

I was excited to hear you talk about information architecture. That's something I only got introduced to last year also. Do you have a general explanation of what information architecture is and why it's relevant to documentation?

Matt Reiner:

Oh, information architecture is, there are whole, people, professionals whose entire career is coming in and helping you. So I'm not one of those professionals, I just play one on TV. Really in essence, information architecture is breaking down what would be a wall of text into a pattern of information that anyone's mind can connect to. That's the real and ultimate goal, and that starts by just breaking up logical chunks. In fact, in a lot of pure technical writing, you break the content into tiny, tiny pieces, chunks or some technical communicators talk about atoms of information, really tiny pieces.

And then once you've broken that down and said, "These are separate pieces," then you assemble them together in an order that makes sense. In fact, you can also do really cool stuff with content reuse in Confluence, using include macros and the new Excerpt Include Macro is very cool in cloud, because you can do new stuff with that. But it's really about breaking apart all your content, figuring out what's the order of all of this? What's most important? What's more specific? What is important for everyone? What's important for just a few people?

And then just going down like you would with an XML structure or any other sort of hierarchy and tier that information using your spaces, your pages, your headings. And then finally bullets and paragraphs and that kind of thing.

Henri Seymour:

Thanks for getting that generally explained. Is there anything you want to mention in your work at the moment that you would be interested in getting readers onto?

Matt Reiner:

Yeah, totally. A major new effort for me, because I'm just this content explorer, I guess. I've done like technical content, I've written some marketing content. I started speaking, which I enjoy speaking. I got to speak in front of one live audience before... No, I guess a few, and then, the world's shut down for good reason. Because when you're breathing out on a bunch of people, you want to make sure that you're not potentially putting them at risk. So been doing a lot of virtual speaking.

But recently, I mentioned, we've worked on all these best practices on Rock the Docs. And so we've started this video series about Confluence best practices and it's been very exciting to figure out, "Okay, so I know how to create fairly good in Confluence, how to structure that content. Now, can we make a good video?" And it turns out, no, not at first. Made some pretty poor ones or ones that just took way too much time to make. And finally, as you do with any kind of content, we finally got a good structure, a good rhythm. And we also found what are those things people really want to hear about?

And so we've developed 16 of these now on our YouTube channel that are just out there for administrators to share with your users who are asking these questions. Or maybe these are for users directly who just want to subscribe and get these things. But it's like eight minutes of just as much information as we can pack and still speak fairly legible English. And then show just like how do you do this in Confluence? Why would you do this in Confluence? What are the things you should consider in Confluence? What are the best ways to do things in Confluence?

We've actually just started a series of live streams as well, where we're trying to look at those more in depth and then have people live listening in, asking questions and directing the whole thing. So far those have been really great and we're looking to do more of that. So the more people who pile into those, the more direction y'all get to give that content. But it's been new types of content that it's exciting to see, okay, our good written content in Confluence is coming to the real world in a new format. Which has been cool and challenging and fun and scary all at the same time.

Henri Seymour:

Yeah. That's sounds like a really exciting project. Rock the Docs is going audio-visual. And I can-

Matt Reiner:

That's right.

Henri Seymour:

... figure what... Get users on there to give you that iterative feedback that we talked about at the beginning. And so is this worth the thumbs up? Do you have comments? What else can we do? And especially in that sort of live stream webinar format, you get that direct contact with your users so you can find out what they're needing. That's that's fantastic. Probably see if I can come along with those. Easy Agile started using Scroll Viewport for cloud specifically earlier this year.

Matt Reiner:

Oh, cool. Oh, cool.

Henri Seymour:

So that's been a major improvement for us actually.

Matt Reiner:

Oh, good. Yeah. I'm just loving what the cloud team is putting out. It's so exciting and so polished and it's just like every team has that documentation space, and Viewport, it lets you put it out there and you're like, "Ah, looks so great. We're so proud of it." You can read it on any device. It's just like it's the magic that everybody wants, but no team has time. Our very few teams have time to make it look that good, so it's nice to have Viewport just do the heavy lifting.

Henri Seymour:

We've got the Confluence space, we've got the documentation. We don't have to make a website about it. It's just, "Go ahead, please make this website happen. Here's what we need on it. Here's the structure." And golly, it looks a lot better now, even just aesthetically, it looks a lot nice in the house.

Matt Reiner:

Yes. And it's nice to know that like some designer peered over the spacing between navigation items to decide how spaced out they should be. And as a writer, I can just like, I don't have to care. I don't have to care. I can throw in Confluence macros and stuff, and they just look really great when they're published. And I don't know how or why, but I'm happy. I can just keep writing. Yeah.

Henri Seymour:

Yeah.

Matt Reiner:

It would be great to have someone from Easy Agile join us for one of those live streams. Because what we're really focusing on is just like great way to do things in Confluence. We haven't jumped into Jira yet. I'm not as much of an expert in Jira, but I have thought about it because that content doesn't really exist yet. But it's not necessarily app-focused or K15t app-focused. It's just like one of the best ways you've found to do certain things in Confluence, and we're just sharing those with people alive, and it's a lot of fun.

Henri Seymour:

Yeah, that sounds great. I've got the parallel of get really into Jira and making Jira apps and Confluence is, "Yeah, we've got a Wiki. This is where we write stuff down." And it is great to have stuff like "There's the visuals on our docs page." But I don't do those. I'm busy making visuals in a Jira app. I don't want to think about that spacing. I've got my own spacing to do.

Matt Reiner:

Yeah. Yeah.

Henri Seymour:

And it really is that, I can just do the writing, I can just do product. I can do my job more because this other stuff taken care of because the experts at K15t have made that happen. And I hope that our apps can do a similar thing for their users of, this is the thing we need, we don't have to think about this. Bring in this app and it will solve a problem for us. It'll help us see what we need to and organize our information in Jira. Which is a different type of information again, but.

Matt Reiner:

Yeah, yeah. It's funny. I've talked with some people who have actually described that whole app part of Confluence in Jira as App Hell. That's a term that I've seen and I can't help but love the community because we all come up with this stuff. But app hell is, it really comes out of not understanding what a platform is partially. For example, if you're using the Salesforce platform, yeah, that's going to be app hell if you really want Salesforce to be a marketing platform. Because Salesforce is a sales platform. But then there's apps, and Salesforce happens to a sell big one. And then all of a sudden it's a marketing platform.

So that is a really interesting perspective shift for people who are used to a tool that just does one thing. Everybody thinks Excel does everything. It doesn't, we really should just use it for spreadsheets, everybody. It's not a platform for other things. Confluence is really good at these core things, Jira is really good at these core things. And then these apps, they come in to answer the questions that don't have answers and do the things that can't be done. And that's why. So is it App Hell or is it App Heaven? That's the real question. Or maybe it's maybe it's App Purgatory, I don't know. I guess the listeners gets to decide.

Henri Seymour:

The constant stream of, and yet another app needs to update. Which to be fair, I think is not a problem on cloud at this point. That's an exclusively an on-premise problem, the constant app update cycle. But we are hopefully moving towards the end of the purgatory perhaps.

Matt Reiner:

Yes. Yes. I think we're all ascending together. We're just reaching new heights all at the same time.

Henri Seymour:

Is there anything else you'd like to bring up while we talking tech docs?

Matt Reiner:

I guess, I typically go back to when I was in university, I had a manager there who told us in this on campus job that I had, "Our job is to connect people with the resources that are already around them. You're not a teacher, you're just here to connect people." And that has really stuck with me. And that is essentially what we all do. Whether we're building a product that connects people with resources or that is the resource or we're contributing to documentation or some kind of content.

We're really trying to enable people to do that greater thing, that higher level thing that is above our content, it's above our product. It's that thing that they truly care about and any part we get to play and that greater thing, that better thing. That's what it's all about.

Henri Seymour:

Yeah, that's really great perspective. That's probably also a really great thing to round off the end of the podcast with.

Matt Reiner:

I guess so.

Henri Seymour:

Yeah. Thank you very much for joining us, Matt, and for talking all things technical documentation with us on the Easy Agile Podcast.

‍

‍

"From beer analogies, to scrum in restaurants and neurodiverse teams, it's always a pleasure chatting with Kit"

Kit talks to agile methodology beyond the usual use case, like working with geologists & restaurant owners to apply scrum.

Kit also highlights the need to focus on a bottom-up approach, providing a safe space for leaders to learn & ask questions, and whether neurodiverse teams are key to effectiveness.

This was a really interesting conversation!

Be sure to subscribe, enjoy the episode 🎧

Transcript

Nick Muldoon:

G'day folks. My name's Nick Muldoon. I'm the Co Founder and Co CEO of Easy Agile, and I'm delighted to be joined today by Kit Friend from Accenture. Kit is an agile coach at Accenture and he's also the Atlassian Practice Lead there. Kit, good morning.

Kit Friend:

Morning, Nick. Sadly only the Practice Lead for a bit of things, but I try my best. It's a pleasure to be with you, for the second time we've tried this week as well, in the lovely world of broadband dependent remote working and things. But here's hoping, eh?

Nick Muldoon:

It's beautiful, isn't it? Now, for those of you at home listening in just so you've got a bit of context, Kit is a father to two, he lives in London, and he's been at Accenture now for a little over 10 years, right?

Kit Friend:

Yeah, September, 2010. Fortunately I met my wife in pretty much the same summer, so I only have to remember one year, and I can remember one by the other. So it helps when I'm trying to remember dates, and sort things through because I'm not very good with my memory, to be honest with you.

Nick Muldoon:

Oh well. So for me, the reason to get you on today, I'm super excited to hear about the journey that you've been on in Accenture, and I guess the journey that you're on with your clients, and on these various engagements. Before we dive into that though, I wanted to know, can you just tell me what is one of your favorite bands from the '90s, from the early '90s?

Kit Friend:

Yeah, and I really enjoy that we had a delay between things, because it's like one of those questions, because I'm like, "Hmm." And I think I'm a victim of playlist culture, where it's like naming an entire band feels like a real commitment. It's all about tracks now with things, right? But I have narrowed it down to two for my favorite 90s band and I think I'm going to commit afterwards. So my undisputed favorite 90s track, Common People by Pulp, right? Hands down, yeah, it's right up there. For me, I studied at St Martins, the Art College, so for me Common People is the karaoke track of my university days with things there. So Common People by Pulp, favorite track.

Kit Friend:

For bands wise though, I was split between... Initially I went Britpop, I was like, "Cool, that feels like a happy place for me." Particularly at the moment in our weird dystopian society, I listen to Britpop and it's kind of happy. So Blur was right at the top for me for band commit of the 90s thing then. But then I remembered that Placebo is actually technically a 90s band, even though I did not listen to them as a 13 year old Kit and things. So I think Placebo edges it for me on favorite 90s band of things, just about. But I do have to admit, even though it's not my favorite 90s track, I do think Wonderwall is perhaps the best song ever written.

Nick Muldoon:

Oasis? Love it.

Kit Friend:

Yeah, for track wise. But for me particularly I was at Oktoberfest with some colleagues a couple of years ago and I don't think any other track could get 600 drunken Germans up on benches together with everyone else, all the way around from the world, with a rock polka band singing at the top of your voices at 11 o'clock at night or something. So yeah, that smorgasbord, but I'll commit to Placebo for favorite band in that weird caveated sentence.

Nick Muldoon:

I love it, thanks for that, Kit. And so it's interesting because you touched on then that you went to St Martins, which was an art college. So I'm interested to know, what did you study? What are your formal qualifications and then what led you into this world of Agile delivery and continuous improvement?

Kit Friend:

Yeah. I mean to do the Twitter bio caveat that all the opinions are my own and not Accenture's before we go down the journey of things. Although it must be said I am trying to convert as many of my colleagues and clients to my way of thinking as possible. But so I studied St Martin or studied at St Martins College, so in the UK certainly, I don't know what it's like in Australia, but when you go and do an art and design degree they basically distrust your high school education. They're like, "Nah, everything you've done before is..."

Kit Friend:

So they make you take what's called, or they advise you to take what's called a foundation year where you try a bunch of stuff. So you come in thinking you're going to be a painter or a product designer or something, and they're like, "No, no, no. You haven't experienced the breadth of the creative industries and things." So I did one of those, which was amazing, and I came in thinking I was going to be a product designer. Ended up specializing in jewelry and silversmithing and things, so I made like... Yeah, sort of wearing long black trench coats and things, I was making gothy spiky armor and all sorts of things, and [inaudible 00:04:24] work with silver. So I do have a Professional Development Award in Welding from that year, so that was my first formal qualification on that. I'm a really bad welder though.

Kit Friend:

Then at the end of it I was like, "I don't really know what I want to do still." As you do as you go through university, so my formal degree title, adding to my trend of very long unpronounceable things, is, Ba Hons Art And Design And The Environment, Artifact Pathway, and what it was was... Your face is-

Nick Muldoon:

Yeah, I'm trying to process that.

Kit Friend:

Yeah. I think the course only existed for three years, it felt like a bit of an experiment, or it only existed in that format. So we had architecture students doing the first part of their architectural qualification, we had what were called spatial design students who were, I think, designing spaces. They weren't interior designers, they were a bit more engineery and then we had this weird pathway called Artifact, which was the rest of us and we weren't quite as strict as product designers, we weren't artists. We were making objects and experiences and things.

Kit Friend:

Yeah, it was a really interesting experience. I mean towards the end of it I began specializing more and more in designing ways for communities to come and build things and do stuff together, and it's a bit weird when you look backwards on things. You're like, "I can directly trace the path of the things I've done since to that sort of tendency [crosstalk 00:05:54] liking bringing people together."

Nick Muldoon:

So yeah, do you think that community building aspect was kind of a genesis for what you've been trying, the community around Agile transformation you've been developing over the past decade, or?

Kit Friend:

I don't know. It's easy to trace back to these things, isn't it? But I guess I've always-

Nick Muldoon:

You don't see it at the time.

Kit Friend:

... liked bringing people together to do things. No. It's a theory anyway, isn't it? An origin story theory as we go. So I did that and then I complained lots about my course, I was like, "This is rubbish. This is all really random and things." So I got elected as a Student Union Officer, so I don't know how it works in Australia but in the UK you can be elected as a full time student politician effectively, and you can do it... You take sabbatical either during your course or at the end of your course where it's not really a sabbatical. So I was the Student Union, served full time for two years after I finished my degree, which is a bizarre but educational experience.

Kit Friend:

Again, it's about organizing people, like helping fix problems and having to be very nimble with... You don't know what's happening the next week, you're going to protest against unfair pay or you're going to have someone who's got their degree in trouble because of their personal circumstances and things, so it's a really interesting mix. So yeah, that's where I started my journey into things.

Nick Muldoon:

So it's interesting for me, because you talk about this, the early piece of that is, "We don't trust anything that you've learnt prior to this and we're going to give you a bit of a smorgasbord and a taste of many different aspects." How does that relate to an Agile transformation? Because I feel like we went through a decade there where an Agile transformation was literally, "Here's Scrum, do two weeks Scrum, story point estimates, no rollover. If you rollover we slap you on the wrists."

Nick Muldoon:

There probably, 10 years ago, there wasn't a lot of experimentation with different approaches to delivery. It was just, "We're going from this Waterfall approach to this Agile approach." Which back then was very commonly Scrum. Why don't we give people the smorgasbord and why don't we give them three month rotations where they can try a bit of Scrum and a bit of Kanban and different approaches?

Kit Friend:

Well, I guess it's practicality, isn't it? These things. It's a challenge, and it's a challenge, it works within a contained place. I teach a lot of our product container courses for our clients and we always use the David Marquet video of Greatness Summary. What's great about the David Marquet situation, he's got this Petri dish, right? Literally a submarine, aint no one interfering with his submarine crew. So he can do that, he can go, "Well, let's try this thing." I vastly oversimplify because it's an amazing story, right?

Kit Friend:

But you've got that space to do something and try something out, and actually when we do talk to clients and colleagues alike about Agile transformations, I think one of the things that I say consistently in terms of the role of leadership is they do need to create a safe space, a little place where they protect and they're like, "In this space we're doing Agile, we can experiment, we can do these things. Leave my guys alone. Trust me within that."

Kit Friend:

I think where I see Agile going well, it is where there is a bit of that safe space protected to do things. I've got colleagues who work in companies where they go like, "Okay, we're going to try now and all we're going to ask you to do is forecast your next week's volume of stories. Everything else is up to you, you can choose to apply Scrum, you can use Crystal, DSDM, whatever it is. All you have to do for us as a company is give us a high level view of these metrics or something." So there's flexibility. I think when I think about your journey as an Agilist and trying to do things though, people saying try a bit of everything, it's lovely advice but it's a bit difficult to actually do because it's like we still need to make things, we still need to do stuff practically.

Kit Friend:

So when I talk to people who are starting off their journey or both clients and colleagues who are wanting to move through things like that, like what do they do first, I still say Scrum is a really good place to start because I think there's that quote from somewhere, it's probably in the Scrum Guide, about, "It's simple to understand but complex to get right." And you would think with complex and chaotic situations, right? But I think that-

Nick Muldoon:

And the discipline required is-

Kit Friend:

Yeah, yeah. But discipline's a good thing, right?

Nick Muldoon:

Mm-hmm (affirmative). But not everyone has it.

Kit Friend:

No. But one of my colleagues, Nick Wheeler, he uses the phrase, "Too many beanbags, not enough work done to talk about Chaotic Agile." I think you've got to have that focus on getting things done, right? Value delivery has got to be there, as well as it being a pleasant working atmosphere and balance. So it's about somewhere between the two, and I like Scrum because it gives people something too... It's a framework, right? It gives people something to hang off to start their journey, otherwise I feel like you could spend months debating whether you have an Agile master and what do they do? Where do we go? Do we have a person who holds the vision and things?

Kit Friend:

I think when people are starting off I always say, like, "Why not try Scrum? Why not see? Try it for a couple of sprints and see what works for you and then see what comes out in the wash." I mean if they're in an area where there's some fundamental contradictions, like, "Yeah, I'm not going to force sprints on a call center, right? It doesn't make sense." I was talking to someone yesterday who works on a fraud team, and it's like I'm not going to ask her how much fraud is going to be committed in two weeks time, or as part of MPI, right? It's absurd.

Kit Friend:

So in those circumstances, yeah, you start with Kanban methods and processes and practices instead. But for people who are building products, building things, I think the Scrum is a pretty good fit at the beginning. So yeah, that's my answer, so both. Why not have both is the answer to that, I guess, on the way. Yeah. It'd be interesting to see what other frameworks rear their heads. I mean I found the other day a scaled Agile framework called Camelot that involved lots of castles and things in the YouTube video. I thought that was marvelous. But there's room for a lot of planning and thinking.

Nick Muldoon:

As soon as you saw Camelot, for some reason my mind goes to Monty Python. I don't know quite why. But what's this flavor of scaled Agile called Camelot? Can you tell me about it? Because I'm not familiar with it.

Kit Friend:

I've seen one YouTube video on it, Nick. For anyone Googling it, you can find it related to the X Scale Alliance. I think it's a picture of the Monty Python Camelot on the front page.

Nick Muldoon:

Is it actually?

Kit Friend:

Yeah, yeah. I'm pretty sure weird things. And you know what it's like with techy geeks, right? There's a lot of embedded Hitchhikers' Guide To The Galaxy and Monty Python references in component names and things. So I'd be unsurprised. What I like about something like the Camelot model, other than me thinking Monty Python and castles and things, is it does evoke something in people. I think when we're talking to people about Agile we do need to evoke a feeling with them. We need to get people going, "Oh yeah, I kind of get where you're going."

Kit Friend:

So I always like to do the cheesy uncapitalize the A, what does agile mean to you? Yeah, is it about being nimble? Is it about being flexible and that kind of thing?

Nick Muldoon:

I mean I'm conscious you've obviously done Lean Kanban in university, you've done Scrum Alliance Training and Certification, Prince2, Scaled Agile of course. Why do you do all these things? I mean is it curiosity? I mean is it there's an expectation from clients that you have these certifications? And would you go and get a certification in Camelot? Or even one that I was introduced to recently was Flight Level Agile, Flight Level Agility. Which is a different way of-

Kit Friend:

Ooh, another one?

Nick Muldoon:

Yeah, another one. A different way of describing. Actually I remember, bit of a sidebar sorry, but Craig Smith from... who was at the time I believe was working at Suncorp, an Australian bank. He did 46 Agile methods in 40 minutes or something like that, and he spent a minute and he introduced people to all of these different approaches.

Kit Friend:

Yeah, and methods versus frameworks and things is a fun one to draw the lines between. I mean I've been surprised actually how few times I've been asked for certifications around things. It's changing a bit more, and I've seen definitely more enthusiasm from our clients, and in fact I'm seeing new people within Accenture which is really nice, to require and encourage certification. I don't think it's necessary that the safe course then guarantees that you're going to scale Agile successfully, right? But it's a good way of demarking whether people have done their homework and have put some effort into [crosstalk 00:14:50] knowledge.

Nick Muldoon:

And they got the foundational baseline stuff.

Kit Friend:

Yeah. Now in terms of your question around Brett, so my view is that if we try and attach the word coach to ourselves... I think I've seen country by country different trends, so when I look at my colleagues in the States there's a bit more codifying on the term Agile Coach. There's an attachment to ICA Agile and Lisa Adkins work and all sorts of different things over there which is good. Certainly in the UK and Europe, I see it as a lot more varied at the moment and it's a term that's attached to a lot of people.

Kit Friend:

If you look at people, just anyone on LinkedIn with a CV title or little bio title Agile Coach, you can see a big variety of people who've been doing different Agile frameworks for like 20 years doing things, and you can see someone who's been a Scrum Master for three months and then switched jobs, and they'll have like Agile Enterprise Coach as their title. And you're like, "Hmm, how many people have you ever done Scrum with? And have you done anything but Scrum?" And my view is if 40-

Nick Muldoon:

But I mean Enterprise Agile Coach because I've done Scrum with my team of six people in a-

Kit Friend:

In an Enterprise, right?

Nick Muldoon:

In Enterprise.

Kit Friend:

But my feeling is if all you can do to a team that you're coaching is offer one way of thinking and one approach to doing stuff, how are you coaching them then? There's no breadth to what you're able to offer. But if all you've experienced is Scrum and then you get landed with a team doing fraud investigation, how are you going to guide them on a path which doesn't include sprints and those things? I mean you might do, because you're going to take things from Scrum that become sensible, but you need that spectrum.

Nick Muldoon:

Give us a sense, Kit, what is the most quirky, or unusual perhaps is a better way to frame it, what is the most unusual team that you have introduced to Agile practices and Lean principles?

Kit Friend:

So I've got to embarrass my colleague Giles, because mine is not the most interesting. So Giles was looking at introducing Scrum to geologists for site surveying and things, which I love as an example to talk about because it's so-

Nick Muldoon:

Wow. Yeah.

Kit Friend:

When you unpack it's so interesting to think about what that would mean, and I need to catch up with him to see how far through they got actually applying it. But because it's like, "Why would you do that?" And then it's like, "Ooh, actually, they probably have a really big area to survey. Wouldn't it better to introduce some feedback loops and look at how you slice down that problem to get some value and learning delivery out of things?"

Nick Muldoon:

That's interesting.

Kit Friend:

So I really, really like that. Yeah. Then I always reference when we're teaching, there's a restaurant called Ricardo's in London that I have to make sure it's not gone out of business. I think it's still in business, but-

Nick Muldoon:

Well, I thought it-

Kit Friend:

Well, COVID, right? I think he's their owner, Ricardo. At least he's the person that's inspired their name. He applied Scrum and it's beautiful, looking at the exercises they went through when they put it in place. And on his website, which I'll ping you the URL for the show notes, but they do this cross functional teaming thing where they got all the staff at the restaurant to look at the role types that they needed, and then their availability and things. They were like, "Only this one guy can do the bar. Maybe we should up skill some other people to be able to work on the bar?" And I love that thinking of applying those elements of stuff.

Kit Friend:

So back to your question though of where have I applied unusual things to my teams, I haven't done any really quirky ones, to be honest with you. I mean I think having a background in art and design I find it... When I talk about iteration and all those areas, my mind immediately goes back to projects where we made things and did stuff and have it there, and particularly when people get panicked in a business situation I think back to... I used to freelance doing special effects with my dad whilst I was at university, because it's a great way to make cash for things. My dad worked for the BBC and freelance. I think about that immediacy and panic when I'm talking about Kanban and handling ops and incidents and things, and I'm like, "You guys don't need to panic, it's not like you're on live TV." And they have a countdown of three, two, one, right?

Kit Friend:

No one has that in our business. We panic sometimes when something falls over, but there's never that second by second delay. So I think the quirkiest places that I've applied Agile thinking are probably before my career in technology. They were in that kind of place where we're making creative things and doing stuff, and it's there where you're like, "You would never do a 400 line requirements document for a piece of product design or jewelry, right?" You would produce something rough and see what people think about it, and build things in so there's a balance there.

Kit Friend:

I mean when you're launching live products though, you do some strange things, right? And you have some fun memories from that. So I remember when we launched YouView in the UK, which is a public credential because it was for Accenture. Fine. But during launch day a colleague of mine, Ed Dannon and me, we became shop display people for the day so we were at the top of John Lewis in Oxford Street in London demonstrating the product, and that was a part of our Agile working for that week because that's what they needed. That was how we delivered value was physically being the people going like, "Hello, Mrs Goggins. Would you like to try this YouView box at the top of things?" So I remember those days fondly.

Nick Muldoon:

And so was that capture on a backlog somewhere, or?

Kit Friend:

Do you know what? YouView is where I was introduced to my love of dura, so I suspect, yeah, I don't think we did formally add a backlog somewhere. It would've been nice too, wouldn't it? I'd like to claim that my entire Accenture career could be constructed out of Dura tickets if I piled them one on top of each other for 10 years. Certainly about a 60%-

Nick Muldoon:

How many Dura tickets do you reckon you've resolved over the years?

Kit Friend:

God. How many have I duplicated is probably the question, right? Which is like 8,000. There's always duplicate of things. It's got to be in the thousands, hasn't it?

Nick Muldoon:

Tell me, you've, okay, over thousands of duplicates resolved. But you've been doing this for a while in the Atlassian space, and obviously with the Agile transformations at scale. How have these engagements at scale evolved over the past seven or eight years? And what do they look like in 2021 with this completely remote mode of operation?

Kit Friend:

Yeah. Starting at the end of that, I see light, I see goodness in things. But I guess similar to how you expressed 15 years ago, 10 years ago everyone was like, "Do Scrum and have some story points and things." I think during that period, if we go back like 10 years ago, so we're like the early 2010s or whatever we call the teens in the decades, I think we see a lot of people experimenting with early versions of SAFE. They'll do wheel reinvention and people simultaneously going, "Let's have a big meeting where everyone plans together. How do we normalize story points? You shouldn't, maybe we should. How do we do metrics there?" And that kind of stuff.

Kit Friend:

So I think certainly what I've seen is a lot of people trying out those things as we go through, and then trying to weave together concepts like design thinking and customer centricity, and there are all these bits of stuff which feel good, but they weren't very connected in any way that was repeatable or methodical or codified. Then what I quite enjoy, and linking back to your last question, is then the branching of the approaches to things. You've got SAFE, which is laudably to everyone who works on that, right? They try and write down everything.

Kit Friend:

I always say this to everyone, you're like, "Thank goodness someone decided to go on that website and make everything clickable and everything." Because when you do need to reference one of those elements, it's a godsend being able to go and go, "Yes, here is the page that talks about Lean budgets. I might not agree with everything on it, but it's a really good starting point. It's a really good point of reference to have."

Kit Friend:

Then you've got the others, and I do use SAFE at one end of detail, and even if you're doing SAFE correctly you don't do it by the book and copy and paste, right? And that kind of thing. But there is a lot of detail and a lot of options there. At the other end of the scale you've got things like Less, where it's intentionally about descaling and it intentionally focused on simplicity. Look at the front pages of the website, and on the SAFE website you've got everything. On the Less website it looks like we've done it on a whiteboard, right? And that's intentional, both of them are intentional at the end of the scale. Then we've got Scrum on the scale, which seems to be the new, rising, kind of darling of things at the moment, and that was the other thing. So what I see now-

Nick Muldoon:

And they all have a place, don't they?

Kit Friend:

Yeah.

Nick Muldoon:

It's interesting that there's a large enough audience and market for all of these to succeed, and there's a lot of overlap between them in the various ideals and practices that they suggest that you experiment with.

Kit Friend:

Yeah. I mean what I've seen in the past few years is that I think people often get laudably enthusiastic about the scaling bit. So they take a look at a word like Lean Portfolio Management or a business problem they have of how can I capacity manage? And they go straight to the scaling frameworks without stopping at the teams on the way, and that's definitely a tendency I hear more and more from friends, colleagues, geeky friends, colleagues, clients, right? They don't make that initial investment in getting the teams going well, whether it's Scrum or whether they're running in anything else.

Nick Muldoon:

Sorry. But hang on, are you saying then, Kit, that people are actually coming into a scaled Agile transformation and they haven't got the team maturity? Sorry, forgive me, but I felt I guess my belief and my understanding was that these scaled Agile transformations, for the most part, are building on top of existing successful team transformations.

Kit Friend:

I think that is how it should work right. We should be going bottom up, or at least to a certain extent. In the SAFE implementation roadmap it talks about reaching a tipping point and having... I mean you can start with Waterfall and the SAFE implementation roadmap, but it talks about ad hoc Agile and those things there. I think when people in large businesses and organizations come with a problem though, they're coming with a big problem and they want to fix that, and yeah, it's a difficult message to land, the, "Hi, you've got one to two to five years worth of getting your teams working before you can deploy the fancy portfolio management Kanban and see a flow of things right." Because people are nice. Most people are nice, most people are enthusiastic, most people want to fix things, and so they want to fix that big scaley thing.

Kit Friend:

But it's difficult to land, the, "No, you've got to fix these things at the bottom." I was describing to a colleague, Lucy, last week, and I said, "If you want an answer a question of how do I capacity manage and how do I balance demand across a large organization, you should imagine each of your..." Let's pretend they're Scrum teams without debasing it for a moment. Let's pretend your Scrum team is like a bar with a row of different glassware on it, and each time box is a different sized pint glass or a schooner or whatever you have. Now, my capacity management for a single team is me with a big jug of beer and I've got all the work that I want to do in that beer. My whole backlog of things. My capacity management for a team is pouring it in and hopefully I guess it right. I probably don't and I spill some beer in the first ones as we go through. But over time I'm trying to guess how much beer I can pour into each time box of things and we go through.

Kit Friend:

Now, the only way that I can know how much I can fit in in the future is if I see what I've got in the past, like how it went and can I predict the size of the glass, and over time I can, and we stabilize. So everything's a pint glass after a while, after we've experimented with everything there. Now, if we don't have that ability to forecast and measure, get the actual data back via some tooling at a team level, how can we manage across multiple teams? Right? You can't. You can't have a big top down roadmap where you're like, "Yeah, we want to launch the easy Agile bank across all these areas and go into the teams." Unless you have that team level maths that you can rely on.

Kit Friend:

It doesn't matter whether that's story points or whether you're doing no estimates stuff and you're just measuring flow or you're using Monte Carlo, whatever it is. You need some mathematical way of helping people understand the flow of work and what's happening there, and ideally tying it back to value with some data. Workout whether is your easy Agile bank actually a good idea or should we pivot and do something else? Yeah, is it delivering the thing that customers want when we've given them easy Agile bank beta at the beginning of things.

Nick Muldoon:

How good do you think clients are these days? So here's the thing, I guess, you talk about early transformations and it was, "Hey, we're going to go Scrum." But now there's the design thinking, I mean there's devops, there's DevSecOps, there's so many different aspects now that people are exploring and they're exploring at the same time. How do you help the client navigate this? Because they get it from every different angle from different aspects of the business, and in fact it's just got to be overwhelming, quite frankly.

Kit Friend:

Well, it's overwhelming for us trying to help right, right? People like yourselves, I mean you're like, "How do we cope with this weird specific configuration that they want to feed into easy Agile programs?" So I think that the light at the end of the tunnel that I referenced before is I see a lot more people coming with an ask of helping them get the bottom up things right, so they understand there's a pincer. We can't ignore-

Nick Muldoon:

Get the foundation.

Kit Friend:

Yeah. But we can't ignore that there's the big business, right? There's the people expecting big things and they've drunk the Agile Kool-Aid, they've read the article and they want to be there. So there is that top down pressure, but I am seeing more and more asking for advice and help to do things at the bottom. On a couple of areas recently, my current theory of the day, and I have a favorite theory every six months or so so this won't be the same later in the year, but I really, really like training the product owners first to help with that transformation. My current theory is that it's because they're like the battering ram to help the business understand what's happening with these delivery teams, and build the bridge and link between things and form that.

Kit Friend:

Because if you don't have the product owners being the conduit and the voice of the business and the customer and the voice of the team back to the business in doing things, I think the rest of it falls down. So my theory at the moment is that if you start by training the product owners that's the best way to begin things and it helps with the scaling body scaling, the focus on the team level to help do things.

Kit Friend:

To be honest, even if they're not doing Scrum, I think that the role of a product owner, relatively close to what the Scrum guy says, if we take out the sprint references and things, I think that's a sensible thing to have in every cross functional Agile team, regardless of what you're doing. And it's a distinct personality type, right?

Kit Friend:

I often talk when people are doing our Agile Foundations course, where we're like, "Here's everything. Find your place." I think that most people, or certainly most people I train, fall quite clearly into a product owner or a Scrum Master style personality type. I'd say about 80% you can tell, like, "You're a producty person. You're a Scrum Mastery type person. Or if you're not doing Scrum, a coach, a facilitator, a team builder." Maybe about 20% can flit between the two, and they're special people. The Unicorns as we have in every industry and type, but most people fit into one of those. I think it's good to think about how those personality types work in your business.

Kit Friend:

The other thing I love about training the product owners first, it really unveils upon them that, let's say, we're now at... "Hi, Nick. Yesterday you were the business owner for this process and doing things. You're now a product owner, go. And you can only have till Monday." If we train you, you're like, "Oh my God, I didn't realize I was now accountable for the value of this whole team delivering. It's my problem to make sure they're delivering good things? I didn't know that." So if we do that training right at the beginning I think it sets a baseline of expectations of what we're asking of those people, and the responsibility that's placed on them. Yeah.

Nick Muldoon:

When you're doing this Agile Foundations course that you run for folks through, are you doing a DISK profile as part of that? Again to assess their personality type.

Kit Friend:

No, no. That would be really good. What a great suggestion. I can include that.

Nick Muldoon:

Well, I'm merely inquiring because I wonder. I'm just thinking about it now, I'm wondering, are there personality types that are more likely to be the product owner? Is a product owner more of a CS and is a... Yeah, I don't know.

Kit Friend:

I don't know. I mean it's one of those things, isn't it? I forget the number of personality types and roles I've been assigned in various bits of my career. I can't remember. Back when I was a Student Union Officer, I'll have to look up the name of it, but we had the ones where, "Are you a completer finisher or a shaper?" And all sorts of those things there, and then DISk was relatively popular. We've got a Gallup Strengths Test within the Accenture Performance Management Tool, which is actually really interesting.

Kit Friend:

The bit I like about the Accenture one is when you join a new team you can bunch yourself together in the tool and see what people's different strengths and personality traits are, so you can be like, "This team's very heavy on the woo. Or you're a team that's full of energy or ideas with things, and it's quite interesting too." I mean it's nice to see the strength, but it's also interesting to notice where you might have gaps and you're like, "I need to make sure that someone's keeping an eye on quality because we all get very excited and run fast."

Nick Muldoon:

Do you remember, this would have to be a decade ago now, I'm sure, but I think his name with Larry Macaroni or Larry Macayoni, and he was working for Rally Software at the time, and he did a very wide ranging study of the effectiveness of Agile teams? And I'm just thinking back on that now, because he was looking at things like defect rates, escaped bugs versus captured bugs and all sorts of other bits and pieces. But I don't think he touched on the personality traits of these teams and whether even Dave the Cofounder here at Easy Agile, my business partner, he was talking. He shared a blog article this morning about neurodiverse teams and I'm just trying to think, do we know is there a pattern of DISK profile distribution, neurodiversity distribution, that leads to a more effective team?

Kit Friend:

I don't know. I haven't read. Yeah, it's Larry Maccherone, but it's not spelt the way I suspected originally. I put in Macaroni, based on your pasta based pronunciation of things. So it looks like it's the quantifying the... What's it called? Quantifying the Impact of Agile on Teams, which is really interesting.

Nick Muldoon:

But I don't know if that sort of study has been done since he did it back then.

Kit Friend:

Particularly the personality types is interesting, and neurodiversity is another interesting element. So I've got dyslexia and dyscalculia, and one of the bits I've found-

Nick Muldoon:

What's dyscalculia?

Kit Friend:

Well, just like dyslexia, there's quite a spectrum covered by one term of these, so it's large. But effectively my particular diagnosis, I have problems processing sequences of numbers. So you can read me out a sequence of numbers and if it's exactly that, I can cope with it normally because I can do visual processing, because that's my creative industries background, it's what we do, right? We visually process. But I can't repeat them back to you backwards, I can't reprocess them as units of stuff with things. My wife says-

Nick Muldoon:

How did you even come across that?

Kit Friend:

So a retrospective again, so my sister was diagnosed with dyslexia at school, and she's got a more traditional dyslexic diagnosis. So when you hear dyslexia, people normally associate it with not being able to read and spelling and grammar and that kind of stuff. Dyslexia, as you might know from [inaudible 00:35:00] is actually... I'm waiting for them to split it, to be honest with you, because it's so broad. But my diagnosis of dyslexia is more about my short term memory processing, so it's the ability to process. I can read and write fine.

Kit Friend:

My sister got diagnosed at school, had blue glasses, all the conventional grammar and spelling related elements of dyslexia. My dad got diagnosed then in his mid 50s, I think at the time. So he started working at the University Arts London, my art college, my dad still runs the woodwork shop in central St Martins in their beautiful new campus in King's Cross in London. He got diagnosed with things, and I was like, "Hmm. I know it's hereditary, I should probably get checked." So I think I was 25 or 26, and one of the lovely bit... I mean there's many lovely bits about working at Accenture, but a large corporation has really, really good support networks and things.

Kit Friend:

So I pinged the right people around, and they were like, "Yes, of course we can support you getting an assessment. We'd love to make sure that you're able to function." So I got an assessment done and they were like, "Yeah, you're dyslexic and dyscalculic on this kind of area." But the more interesting thing was that they were like, "Here's the coping mechanisms that you've developed." And the coping mechanisms was a list of my career and choices and education. It was like, "You will choose things where you can do abstract thinking and drawing." It was really funny because I never felt like it blocked me at school, I quite enjoyed exams and things.

Kit Friend:

But I was terrible at revising, right? I can't go through notes and do things there. Looking at my diagnosis I was like, "It's because I don't process things that way." I have to process things visually, I have to draw, I have to chunk things. Now I look at the way that I work with Agile teams and I coach teams, and I create abstract references to things, right? I'm teaching product owner and Scrum Master courses on Mural where we move things around and create objects.

Nick Muldoon:

Or the example that you used before, Kit, with the beer glasses at the bar.

Kit Friend:

Yeah. I can't deal with numbers in abstract, right? I have to deal with them in an analogy or I have to be able to visual them. I'm hopeless at coding, I can't store concepts like variables in my head. They just fall apart, it's like building with sand in front of me and it's all dry and crumbly. And I think in fact when I looked at that diagnosis and I was still, what? I'd be like three or four years into my career at Accenture. I looked at the way that I'd begun to get slowly addicted to tools like Atlassian and Dura, and I was like, "Ah, I'm compensating for the fact that I have basically no ability to memorize things in the short term." I'm helping visualize stuff in the way that I help teams and build tasks and things, in a way that means I'm outsourcing my short term memory to this lovely tool where we do things there.

Kit Friend:

Yeah. I've grown to love it, I think you have to work with it right. I speak to some of my colleagues, I teach at the moment with an Agile coach called Lucy Sudderby and another one called Charlotte Blake, and I'm like, "Thank you, guys, for compensating for my dyslexia. I appreciate that you kind of balance out my inability to memorize anything." Yeah, hopefully they feel they benefit from some of the quirky strengths of it when we go through, but it's a balancing act, right?

Nick Muldoon:

That's very cool. Thanks for sharing that.

Kit Friend:

No worries.

Nick Muldoon:

I'm just thinking about it now, as you mentioned coaching with Lucy and Charlotte, and going back to something that you said earlier, Kit, with respect to... I don't know if you said the leaders, but basically the folks at the top drinking the Kool-Aid. I'm interested to know, how do you create, going back to this other thought that you had, I'm trying to connect dots, going back to this other thought that you had right up at the top about the psychological safety, right? And that feeling safe. How do you provide a safe space for these leaders that could be CEOs of business units or execs, GMs, whatever they happen to be, provide a safe space for them to actually ask questions and do Q&A and learn without feeling?

Kit Friend:

Yeah. Because we forget that they're people too, right?

Nick Muldoon:

Yeah.

Kit Friend:

There's this idea that these leaders are somehow insurmountable, they have no fear. But we need to build a safe space for everyone around things, I think you're right. I think we get the same sort of question when people talk to me about how they can convert people to Agile or make the case for things in an organization but not sure about it. I think that the answer, relatively saying, in that we need to give them some data, some facts. So my view is that it's not good to come to people and talk about...

Kit Friend:

I somewhat cynically criticize when people talk about Agile ways of working, and they'll often abbreviate it to WAW or something as well. I think when we talk about agility too abstractedly, and I say the phrase wavy hands too much, but when we talk about it within specifics too much, it encourages a sense of anxiety and it's a nebulous, wishy washy kind of thing so I like to bring some data to people. My favorite ones to use, and I need to get updated stats, but the Sandish Chaos Reports are an amazing project management journal, where they talk about success and failure of Waterfall versus Agile projects.

Kit Friend:

Now, there's a bunch of questions it leads you to about how do they classify Agile and all sorts of things. But indisputably, what it tells you is that the traditional way of doing things that we are told is secure and safe, if I go to a procurement team or a finance team and I go, "I'd like to build this thing, guys." They're like, "Great, give me the milestones, give me the plan." And there's this inbuilt assumption that that's a safe and responsible and proven way to do things.

Kit Friend:

The Sandish Chaos Reports tell you it's a terrible way to do things, right? They're like, "Statistically, doesn't matter what you're building, what industry, what you're doing, it's a terrible idea to fix scope at the beginning, trust your plan and have a system which fails when you have any change." And when you unpack it, like when we talk about agility overall, what are we saying? We're saying it's not a good idea to begin something and for it only to be able to succeed within fairly tight boundaries, where no one changes their mind for the duration of the thing, everything goes exactly as you plan and when does that ever happen with technology? And the world doesn't change for the duration of your thing.

Kit Friend:

Most of the time when we're talking about these project things, like how long are they? Three months to three years is the window I usually give. Three months, I see rarely in any industry these days, right? These big efforts where people are trying to do these things at scale, you're talking multiyear. What are the chances that the scope can be frozen for that period? Pretty low, and also what's the chance that the people that you asked for the requirements at the beginning really knew them all? Everyone's normally really nice, they try their best.

Nick Muldoon:

The chance that the people you ask at the beginning are going to be there when you actually get to the next-

Kit Friend:

Yeah. There's a whole set of fundamental problems with that. So I like to bring that kind of data to our leaders when they're asking about the case for agility, so it's not about, "Do you want to sign up to use a framework?"

Nick Muldoon:

But let's say, Kit, that they've made the case for agility, they're there, they're doing it. What's the space that you provide for them? Do you have a CEO round table where they can go and they've got a shoulder to cry on and go, "This Agile transformation is going harder than I thought it was going to be"?

Kit Friend:

Agilists Anonymous, [crosstalk 00:42:19] company. Yeah. I think it is a good idea to pair them up, so I get a lot of requests at the moment for us to provide coaches directly to support leaders. I've also seen a trend in reverse mentoring, separately big companies. But that kind of idea of, okay, you've got these people who are really experienced, and their experience is relevant, right? We're not saying that the CEO's 30, 40, 50 year career in something is invalid now and we know better than them. But they're trying to match that up with these, not even emerging, right? Because the Agile Manifest is 20 years old now. But they're trying to match these up with these foreign, new practices and things they've got, and that requires a bit of hand holding. So yes, there's a personal angle there. I don't think necessarily a round table is the way to do it per se, but giving them someone that they can chat too and, yeah, an ability to relate and go like, "What is this thing?" And decode the jog, I think is really useful.

Kit Friend:

So data about success rates is important, right? But the other data that's really important I think to help provide that sense of safety is about value delivery, and this is where I think most people are still having trouble. We've just about got to the point where people can start to attach a concept of benefits and value at the start of things. Now, often that's still too big. We talk about the value of the entire project, can you assign a notion of value to every epic and story in your backlog or whatever units of stuff you're doing?" Probably not, right? Can you do it in a pound or dollar or euro or whatever your local currency is figure? Probably not. But can you even rank them one to 10? Maybe with things.

Kit Friend:

So I think the evolution of OKRs and KPIs coming in, and people starting to internalize that more, offers some hope. It's still relatively immature in most organizations and you're still kind of getting there. I feel like every sort of practice and things, it's probably going to have some misinterpretation, enthusiastic and well meaning interpretation, but you're going to get some people using it somehow to Waterfall things probably in some areas. But bringing that data that gives them some sort of feedback loop that makes sense to those people in those senior positions I think is really powerful. The opposite of this is where they expect to see RAG statuses and milestones and that's the only data they get from their teams, right?

Kit Friend:

I sat down with an executive of an organization a few years ago and I was like, "Please invest in your tooling. Please do it." And he's like, "Why would I need to? I have these slides where they tell me green and the dates are there." And I was like, "I love that you're trusting, and I like to trust." The trust in the teams was really, really good. But I knew the teams and I knew they didn't have any tools. It was project managers getting stressed and running around, and then I knew that all the RAG statuses were going to go, "Green, green, green, green. Red." It was the Watermelon Effect that was going to happen, right?

Kit Friend:

So when I see conversations like that happening, I want to empower them. I want to empower them with data and bring those things together. I think that data about why doing Agile is really important, the data about how it's really going on your teams, and the ability to make decisions based on it is really important. There's the Scrumming case study on the Saab Gripen is lovely because they, in one of the articulations, they do the sequence of morning standups and allegedly, according to the case study, I'm pretty sure it's true, they do 7:30 in the morning, which is insane. I don't know why they start at 7:30 in the morning in Sweden, but apparently they start at 7:30 in the morning. But they do a sequence of standups and the idea is by the end of the hour the cascade of standups means that any impediment can reach the executives within the hour and they can fix it.

Kit Friend:

That feeling of connection, that trust in teams and that show of progress, real working things being the way that we communicate that we're making progress, I think that's how we build some safety in and help our leaders do things. Not RAG statuses and milestones and Gantt Charts. They have to have that realness with things, hopefully.

Nick Muldoon:

It's interesting. It makes me think, we did a factory tour recently and it's a factory that makes air conditioning manifolds for commercial buildings, and they actually-

Kit Friend:

What? Why were you touring an air conditioning factory? Were you buying some air conditioning?

Nick Muldoon:

No, no, no. Lean principles, right? You want to see the application of the principle.

Kit Friend:

Wow, you're living it, you're living it. It's wonderful.

Nick Muldoon:

Yeah. So they do breakfast from 6:15 to 6:45 or 6:30, something like that, and then they get going. I think they do their standup at 7:45 after they're actually in the flow, they come together, "Okay, where are we at for today? What are we working on?" Then that rolls up to the ops team and then that rolls up to the leadership team, and then at the end of the day they do their closing huddle for the day, "Hey, have we got all of our tools? Are we back? What are we going on with tomorrow morning?" So it was like the start and the finish of the day and it's really interesting.

Nick Muldoon:

Just thinking about, we introduced an end of day huddle in COVID, when we were all on Zoom all the time, and I think it was very useful. But then of course as we get back into the office, it drops away. It's interesting how things evolved, right?

Kit Friend:

Yeah. And you're the big Head Honcho, right, Nick? I have a worry niggle with end of day meetings, about whether they're for the team they're for people to feel they're across stuff, and I find it interesting because I'm having to take people through practicing for Scrum Master exams and things, lots at the moment, and I really like talking about how standups are for the team. They're for the developers, they're not for the product owner even, they're certainly not for the stakeholders. Now, I consistently see with a lot of these Agile ceremonies, I'm like, "Who's getting the benefit from that meeting? Is it someone getting a status check in or is the team getting it?"

Kit Friend:

And if the team enjoys it, if the team gets something from the end of day huddle and things, I'm cool with it. But sometimes I see things, and the two anti patterns I see with leaders joining, of any level, joining the meeting, so the first is that they use it as like their aeration platform. The team's ready to go with their standup and then the leader of whatever level pops in and he's like, "Team, I've got this update for you." And then it's like 10 minutes of their amazing update and mini vision for the day, and then at the end it's like people are going, "Yeah, now do your standup. Now do the Scrum kind of thing." And then the other thing is that where it becomes like a status check in for stuff, and I'm like, "It's not what it's for, guys. We should be focused on [crosstalk 00:48:57]-"

Nick Muldoon:

We do. So we can get done with 22 people in six to eight minutes.

Kit Friend:

That's slick.

Nick Muldoon:

It's taken time to get here, but what we actually started out asking for was one good thing, and that's typically a family, community thing, what are you going on with today, do you have any blockers? And it's interesting now that we're having this chat, Kit, I do not see blockers come up very often, so I wonder why that is.

Nick Muldoon:

Yeah, anyway. Hey, Kit, I'm conscious of time. I've got one last question for you.

Kit Friend:

Yeah, go for it.

Nick Muldoon:

What are you reading at the moment? What books are you reading or have read recently that you'd recommend for the audience to read?

Kit Friend:

Yeah, I'm between businessy books. I need to find a next one. One attribute, and it's probably not my dyslexia, I think it's just because I'm lazy, I'm really bad at reading business books, like serious books with things. So I rely on audiobooks lots to consume meaningful data. I really, really enjoyed listening to Lisa Adkins Coaching Agile Teams audiobook when she released it, because I knew I wasn't going to get through the book and so-

Nick Muldoon:

Did she narrate it?

Kit Friend:

Yeah, which is even better, right?

Nick Muldoon:

Cool, yeah.

Kit Friend:

So lovely to hear from the authors' voices when they're doing things. So I'd really recommend that, and then accompanying it after... I mean either way round, listen to the Women In Agile podcast series on coaching Agile teams, because they talk about each other and there's a whole episode on language, and she talks about how between writing the book and narrating the book, reading it, there was bits of language where she just cringed and she was like, "I can't believe I wrote that." And it really resonates it with me, thinking about my Agile journey and how I would cringe at what I did with teams five, six years ago. As we all do, right? You look back with hindsight.

Kit Friend:

So Coaching Agile Teams is really, really good, and I'd recommend. When [crosstalk 00:50:54]-

Nick Muldoon:

Isn't that beautiful, right? Because if you look back and you cringe, it shows that you've evolved and adapted and you've learned, and you've improved?

Kit Friend:

Oh yeah, if you look back and don't cringe, either you were perfect which is unlikely, right?

Nick Muldoon:

Unlikely. Unlikely.

Kit Friend:

[crosstalk 00:51:07] things, or you're oblivious which is more likely. I don't mean you personally, Nick. So Coaching Agile Teams is really good, I still recommend the Whole Time if people are trying to get their head round what it's like to work in Agile, what's there. I used to recommend The Phoenix Project, and then I really enjoyed The Unicorn Project more for filling in a team. Your talking about the air conditioning factory just reminded me because of all the Lean kind of things. I really like that, and I struggle when I explain to people because I'm like, "It's not dry, it's a novel about an Agile transformation, but it's not [crosstalk 00:51:42]

Nick Muldoon:

It's not. I love it. I get up and I read the newspaper, right?

Kit Friend:

Yeah.

Nick Muldoon:

That's my thing in the morning, and I would never read a business book at night. But The Phoenix Project and The Unicorn Project, I've read them several times as bedtime books.

Kit Friend:

Yeah. To your kids, Nick? Do you sit there [crosstalk 00:52:01]

Nick Muldoon:

I will. I'll get there. I'm starting to teach them about Lean principles, build quality in. Yeah.

Kit Friend:

Yeah. If you haven't done it already, getting your kids to story point Lego is really amusing and I've enjoyed a lot. I know it's just like time gym, but I enjoy doing it with my son, Ethan, because you know how difficult it is to get adults to get relative sizing in units, and kids just get it. It's wonderful how they just don't get distracted by the fact that you've got an abstract unit, and they're like, "I get that idea." I got Ethan story pointing in five minutes, I've struggled to get some adults story pointing in like five days and they argue about, "Do you mean it's days, ideal days, hours?" Things.

Kit Friend:

So yeah, Unicorn Project I think are really good. I haven't actually read it all yet, but I do want to read and I recommend the whole time because of a really good podcast, 99 [inaudible 00:52:51] Invisible Women by Caroline Criado Perez. So when we talk about being customer centric and about really knowing who we're providing our products for, I think there's a really powerful story around making sure we understand the data and when we're going through, and Invisible Women has some amazing, horrifying, but amazing stories and bits of data and narrative around it. So I think those would be my three at the moment, three's a good number to ask people to start with, isn't it?

Nick Muldoon:

Okay, cool. Kit, this has been wonderful. My takeaway is I've got to read The Invisible Woman, because I haven't heard that book.

Kit Friend:

Invisible Women, there's lots of them is the problem, Nick.

Nick Muldoon:

Invisible Women, okay. Thank you. That's my takeaway that I've got to read. Kit, this has been beautiful, I really enjoyed our chat this morning.

Kit Friend:

It was a pleasure as well. Thank you so much for having me, Nick.

Nick Muldoon:

I hope you have a wonderful day, and I look forward to talking about this journey again. I want to come back and revisit this.

Kit Friend:

Yeah. Let's do a check in. We should do our DISK profiles for the next one maybe, and we can find out maybe I'm meant to be a product owner and you should be, I don't know, you'll be like test lead or something it'll say. I don't know. We'll find out.

Nick Muldoon:

It's beautiful. All right, thanks so much, Kit. Have a wonderful day.

Kit Friend:

And you. Bye now.

‍