Since leaving the Royal Navy about 7 years ago, Jac Hughes has found himself drawn to the world of Scrum and agile software development. He now runs Everyday Agile, an agile coaching and training business based in the UK.

In this episode

• How Jac got into Agile and Scrum
• Learning from a wide variety of organizations, from simple to complex
• What does "Agile" mean to you, and how is it different from "agility"?
• What is the relationship between Scrum and agility?
• Picking and choosing the elements of Scrum, SAFe, LeSS, and other approaches, that work best for the context.
• When is Scrum the right or wrong fit?
• Top-down vs bottom-up agile adoption
• How agility permeates the business, not just development, from client contracts to recruiting and onboarding, and everything else
• How to decide on an agile approach, whether Scrum or something else
• Does Scrum work when cross-functional teams aren't possible?
• Biggest misconceptions about Scrum
• How to start adopting Scrum
• Does Scrum make sense for a platform, operations, or DevOps team?
• Thoughts on story points, estimates, and #NoEstimates
• How important is official Scrum training or certifications?
• When and how should a team find external help when implementing Scrum?

Resources
Book: When Will It Be Done? by Daniel S. Vacanti
Blog series: Story Pointless (Part 1 of 3) by Nick Brown
Podcast: Scrum Master Toolbox

Guest
Jac Hughes
LinkedIn: jac-hughes
Everyday Agile
YouTube channel: Everyday Agile

Transcript

Speaker 1: Ladies and gentlemen, The Tiny DevOps Guy.

[music]

Jonathan Hall: Hello, everybody. Welcome to another episode of The Tiny DevOps Podcast. I'm your host Jonathan Hall. On this show we like to talk about solving big problem problems with small teams. Today, I'm excited to have Jac Hughes with me who is I guess an Agile coach, Scrum advocate. We're going to talk about Scrum today and how it fits into the picture of software development and DevOps and all these fun things. Before we dive in Jac, would you give us a brief introduction? Tell us a little bit about who you are and what you do.

Jac Hughes: Yes. First of all, thank you for the invitation. I know you sent it a while ago, but it wouldn't have been of any value in the old house because the internet connection was horrendous, so I appreciate the patience. I also like what you've been doing lately in terms of course-correcting people in terms of what MVP really means. I've been following you trying to gently nicely educate people.

Yes, well done for that I suppose. Some people go for the jugular and you're wrong and this is the way it should be, but I think the way you've interacted with people has been really great.

Jonathan: Thank you for that.

Jac: I'll give you the short version. I left the Royal Navy in 2015, after just shy seven years. Then for one reason or another, fell into a junior project management role, very traditional in a bank in the UK. I was-- because it's what I was used to, I was quite process-driven because that's what the military is all about to a certain extent. Entering the corporate world, I came in with a fresh pair of eyes.

I was quite good at identifying areas of waste and questioning. I was like a baby project manager. Why did you do it like this? Why are you-- That doesn't make sense and sort of thing. Which went down well with some, not so well with others. Who is this upstart trying to open the bonnet of what we do in this legacy driven organization. Then I found Scrum first to be honest. I think many people do. Again, because I was more process-driven, the process side of it, the sequential nature of it, it made sense to me.

Without really realizing I'd been doing elements of that particular framework in my military life, daily huddles, having visual lists to do small cross-functional teams, although nothing thing to do with IT the foundations, the intent of it for want of the better word, just made sense to me and I thought, "Oh, I quite like this." Then you, like Alice, you fall down the rabbit hole of Agile, the capital A and more importantly, agility in general.

Then it just kicked off from there really. I left that organization to pursue the Scrum master route, worked in a couple of places and then set out on my own and that's what I've been doing. Relatively short-- What are we now? 2022, so seven years. A relatively short period of time, but my enthusiasm and passion for it has catapulted me because I felt like I finally found something, one, I'm quite good at and so I'm interested in. You then pursue it with everything you've got and that's probably the two minute version.

Jonathan: Great. Now nowadays you're part of-- Your organization is called Everyday Agile, is that right?

Jac: Yes.

Jonathan: Your content creation as well, I see you have videos frequently and frequent at least LinkedIn posts. What does your day-to-day look like these days?

Jac: It's changed significantly because it was just me as a single contractor just on my own. Then for whatever reason, the LinkedIn stuff is interesting because there was never-- I always say it's the death by 1,000 cuts strategy. There wasn't any real thinking behind it for a number of years. It started off with posting, trying to help people who are leaving the Armed Forces. This is what I've done. This is what to expect from the corporate world. It might strike a chord, it might not, I can only tell my story.

Then I started talking about Scrum, then I started talking about Agile, Kaban the whole sort of shebang. If it's a strength, I can write the way I talk. I think for people who are new to this world or to this community, I think I'm able to speak in a language that rings true. I realized early on from a marketing point of view that I'm not marketing for people already in the community and that comes with its own challenges because as you know, I'm sure you've had it yourself, there's a bit of pack mentality sometimes.

I write a post for Jim or Janet who are in HR, they've heard of this Agile thing, but they don't really understand it. I'll write a post or make a video that tries to simplify it. Then you get the, [onomatopoeia] "That's not--"

I realized that I'm not marketing the people who are already involved because their level is so far beyond the muggle if you like, the person who is trying to dip their toe in the water. I built the business off LinkedIn content. There's no doubt about that and it's just been constant every day trying to think of something. I didn't really know content marketing or copywriting was even a thing until someone said, "Oh you do content marketing." I was like, "Well, I suppose yes I do." I was just trying to tell stories to bring things to life really and that's worked in my favor.

Jonathan: Good. What clients do you typically work with then? Or is it usually individuals or organizations or what?

Jac: Normally organizations. The one that's taken most of my time at the moment is in the defense sector. Obviously I can't-- I'm not being dramatic, but I can't talk. I can't go into masses of detail, but it is probably the most complex environment I've worked in and then there's other people who are the business associates of everyday Agile, who are in there as well doing fantastic work.

The literal politics in terms of it's in the defense sector and there's government involvement. Then you've got the different organizations who are involved, all trying to go in the same direction, but then the internal politics of that, all trying to work together, all with different goals, all with different ideals, all with different understanding of what Agile means to them. It's not software it's more of a hardware thing.

Sometimes a tiny bit of knowledge from leadership can be quite dangerous because then it spirals it. They start using terminology and it's like, "Do you know what that means?" Have you read one article and you've just thought that that's the way to go or have you put a bit more thought behind it. It's definitely complex, it's definitely a challenge. Apart from that I've done with that client in retail, oil and gas, not so proud of that one, but medical industry, education.

I've just tried to collect as many clients as possible selfishly, to learn from different organizations. One minute, I'm talking about something in the defense sector and then two days later, I'm talking about how to get pet food to people's doors quicker. The context switching can be a challenge, but it's something I tend to thrive off.

Jonathan: Let's get to fundamentals for just a minute. I want to talk about different organizations, but first you said sometimes it's a challenge because different people have different concepts of what Agile is. What's your concept of Agile? Let's talk about that, try to get everybody who's listening on the same page, so we know that we're talking about the same thing. Yes, just briefly, how do you define or describe Agile?

Jac: I think agility is starting to be more important than agile with the capital A, and in terms of business agility. I've never been with a client who doesn't want to talk to-- Who doesn't benefit from, whether they want to early on and that's another question, so I'll reword that. Who doesn't benefit from eventually talking to the customer earlier and more often, having shorter release cycles in terms of getting code out into production, having better conversations with the people in the organization to see what their intrinsic motivation is and to hopefully get it a tiny bit less wrong. If you take all of the the buzzword off the table I think that would be my, well today anyway that would be my four point agility manifesto if you like.

Jonathan: All right. Then how does Scrum fit into that just in other words?

Jac: For me, I think I've definitely been on the journey of you do Scrum by the book. I think if people in our community don't admit that I think that they're a bit delusional. I think we most of us do go on this journey of we find Scrum, we fall in love with it. It's the be and end all. We put the Scrum police hat on from time to time when we're early on, the guide is the guide. I do get that.

Arguably, if you remove one thing from it that isn't Scrum anymore, but I think it will continue to have its place, but as one evolves in their own career and working from organization to organization, and that's why I've been collecting clients to prove my own theory that you have to be honest and say, "We can take some things from this framework, which will work really well, but if we are in a defense or a defense environment that's tightly governed we're not really building a product. We're building theories and looking at algorithms of can this thing do that thing."

That takes a long time and there's a lot of cover people who do that and you know what? Yes, having a daily Scrum or daily standup, whatever you want to call, is probably helpful. Yes doing some refinement to look into the future is helpful, but we're not releasing anything just yet to the customer because the governance is constrained by that and that's okay, but let's just be honest about it.

If we're not doing Scrum, let's just except that we're doing 80% of it and we will work to get to 100%, but at the moment, let's stop saying we're doing Scrum when we're not, because that's okay and I think that needs to be promoted a bit more because I'm sure-- I don't know about you. I go into an organization, yes we're using Scrum. You start kicking the tires a bit and it's like, "Well, are you really? Where's the definition of done?" "Oh, we don't do that there." That's fine but that's not Scrum. Let's just be honest about it, I don't really care.

Jonathan: Yes, exactly. When somebody tells me they're doing Scrum then I have a list of expectations. When those expectations don't match reality then at minimum, I'm confused and everyone else will be too. The words ought to have some meaning otherwise, they just become meaningless.

Jac: Ultimately, it might not be the right fit. If you're focused on a continuous flow of work and you are-- Last year, worked with a HR team. They arguably weren't building a product. They just had onboarding, they had recruitment, they had health and safety. It was an oil and gas HR, so they had [unintelligible 00:14:03] if there's an accident on an oil rig they had to sort that out.

It was just a continuous flow of work, so we gave them the options. This is what agile is, this is what it isn't. These are the two most popular ways of working. You've got Scrum, you've got Kanban. This is what each one tries to achieve or help you with and they chose Kanban and that's fine. I think you have to-- And I think the same goes for scaling sometimes. I try and think of it as a pick and mix of suites, so PI planning might be a good idea.

We take that bit from Safe, Sprint planning one and Sprint planning two from large scale Scrum. That might also be a good idea. You combine them both, you've got quite a good rigorous, but not rigid scaling framework there instead of saying we have to do X, we have to do Y, because would send everyone on a course and that's the path we have to go down. Let's just take the bits we need.

Back to the original point, I think I've been on that journey of Scrum police too. Do you know what? What's going to be the best thing for work to flow for the team because often, these conversations about Agile, Scrum, this, that, they're done by middle management and the engineers are not involved and they get it. They just want to build stuff. They want to do some exciting things.

I think we have to remember that a lot of this is a technology problem or a technology opportunity not a process, not an argument about which process we do, because if we can't push codes of production then we can say we're doing Scrum all we like, but to what end?

Jonathan: You talked about working for a large variety of different clients. I'm curious if you could maybe give just two or three examples of some of the biggest outliers in terms of which process or what made sense. You already mentioned working with an HR group that wasn't delivering software. Do you have other examples where Scrum just wasn't the right fit, maybe even Kanban wasn't the right fit, just because they were doing something so unusual.

Jac: Again, it was last year and last year was a big learning experience for me, because it was the first time I'd actually walked away from two engagements because it didn't fit with my own values and principles in terms of how it was being-- I can't think of a better word, but implemented or introduced. It was a marketing team for telecommunications company and they had invested in people, which is great and they've invested in sending people on-- I have no involvement in this, so I came into it a bit later on, but they'd invested in sending people on Scrum course. Great, fine, brilliant. good for people's development.

They literally went on these courses, two, three weeks before. It got to the Monday say, it was the 2nd of April and they turned their teams into squads of Scrum teams and said we're now agile using Scrum. There was no pre-work in terms of, "Okay, well these teams are not cross-functional, they've still got a ton of ongoing work." We've got Scrum masters who are Scrum masters in title, but they're still doing their day job as well.

The scrum master role was seen as a side of desk thing. The usual, they book the events, they facilitate and that's it. It's just turned 30 teams on instead of going through a pilot stage, let's try it with one team. All of this advice was given, but it just wasn't listened to. It was like, "Well back to back to the same point before." Some of these marketing campaigns are going on and on and on and they're planning in the future, Scrum might've been the right fit, but not for every team.

You can't just turn 30 teams on and expect them to be Scrum teams. That was one unfortunately, I just thought, "This isn't for me." I think some leadership engagement, coaching, training, mentoring, whichever flavor would've been really helpful. An impact map and really digging into Mr. or Mrs. leader, are you aware of what you're asking for, because telling a team to go and be agile or do agile is very easy, but if you don't educate yourself on what you're asking for, it's going to be a challenge for you and the teams.

Jonathan: What do you make of the top down approach to Agile? One of the principles in the manifesto of course is-- I don't remember how it's phrased exactly, but it's in Scrum, the idea of self-organized teams and autonomy of teams. Does it even make sense logically for management to say, "Now you're doing Agile," or is that an oxymoron?

Jac: I do believe in bottom-up change to an extent, but I think you can do some great work at the team level and that will do some, that will produce some surface level results, but I think there needs to be a meeting of we've done some great stuff down here, but if the leadership again, on educators and bought into what they're asking for themselves, I think bottom-up change can only go so far from my experience anyway, and I'm happy to be, perhaps to be corrected or proven wrong. I can only speak from my own experience, but yes, bottom-up change can happen at the surface level and maybe a bit deeper, but unless your leaders are brought in, and it goes so far beyond just the engineers now.

How we contract, how we onboard people, how we recruit people, how we monitor their performance. It's massive and I think it's still, although it's 21 years old, massively underestimated in terms of what a small A, agile organization looks like.

Jonathan: Yes, that little four-point document has such a profound impact on the way that an organization works, doesn't it? It's almost scary.

Jac: Yes, speaking for [crosstalk]. I'm in the middle of a product donor workshop at the moment. I was thinking about this a lot. I can't speak for those gentlemen who were-- I was 11 when the manifesto created, so I wasn't there, but I don't know if they ever expected it to turn into what it has. This is just my opinion. I think it was a meet-up as we see now everywhere and they came up with these four values and 12 principles. I don't think they ever imagined it was going to turn into this whole industry, but I could be wrong, so it's no wonder that they are still protective over it.

Jonathan: You mentioned that in the example of 30 teams, maybe it doesn't make sense for all the teams to be doing Scrum. How do you decide when it does make sense to do Scrum and when it does make sense for something else? What are the criteria you look at?

Jac: I would always say you need to identify a pilot team and the cost of entry to that pilot team would be, "We're going to have some opportunities." You may call them challenges. Not you personally, but the organization may call them challenges. Let's call them opportunities. They're going to be unearthed. Have you got a stable team in terms of the people who are going to be committed to this for a period of time? What's the technology stack at the moment? How can we bring the cross-functionality of the team?

In some organizations, UX and engineering are still quite separate. Well, are you open to them being combined together just for this pilot? Just trust the process, but trusting the process requires-- Again, people don't like the word buy-in for some reason, but I think people need to buy into the idea of experimentation even just to prove that it doesn't work. I think that the category to answer your question, the boxes to answer question, would be a small pilot team who are dedicated to the experiment.

A stable enough technology stack that some good code and some good products can be released quicker than usual, and a strong sponsor who will help the Scrum master Agile coach, whoever, and more importantly, the team, ring-fence that team to give them the space to thrive. Don't get me wrong, the experiment still needs to show some data or the outcome, did we achieve it or not? I think they would be the three, I would say today.

Jonathan: All right. You keep talking about cross-functional teams and that's part of the idea of Scrum. Some of the pushback I often hear about Scrum is, the cross-functional team doesn't make sense for us or in our situation, or we don't have enough people, we don't have enough UX designers for that, or whatever. How do you address that? Is there still room for Scrum or do you need to take a different approach in one of those places?

Jac: I think there is again, but it comes back to honesty for me. Say we have a team of engineers, by engineers we'll keep it simple. I just label them as frontend, backend devops just for now. Don't @ me. This is just a basic example. Then we've got a separate-- The designer is over there somewhere. Scrum can still be your framework of choice, but the organization has to be willing to accept you are not going to see or potentially not going to see all of the benefits from having the team together.

It's highlighting the fact that the UX people are going to be context switching, they're going to be-- If you're a UX designer and you're across many teams, that's potentially two to three daily Scrums, two to three sprint plannings, two to three sprint reviews, so on and so forth and that's just a fact. If we're okay with that, then your Scrum might have some success, but how does that UX person then feel about going to all of that? They're probably going to be burned out.

Again, it's that buy-in to experimentation. Let's just put this UX person on the team for three weeks. If it hasn't worked after that three weeks period, or whatever period you choose again, that's okay. We can try something else. I think, to answer your question, Scrum could still work. Will they realize all of the benefits? That is the question that they have to be open to answering.

Jonathan: What are some of the biggest misconceptions you hear about Scrum?

Jac: That it's the automatic go-to? We're Agile now, we'll use Scrum. I think I've labored that point enough in terms of it might not be. There's a toolbox, the old analogy of a laborer will use many tools and picking the right tool for the job. Misconceptions. The Scrum master has to be at everything, so they have to facilitate every event and they are the only person who can remove any impediments or blockers. I think that's a big one. The Scrum must be the admin person. Again, that's the person who buys the donuts and the coffee.

Jonathan: As long as somebody buys the coffee and the donuts, I don't care.

Jac: Yes, I don't care who that is. The definition of donor is a choice. I think that's probably-- I might change my mind later today, but I think the definition of the donor is probably the biggest thing that can help teams if they're utilizing this particular framework because people don't like the binary nature of scrum sometimes. We've either done it or we haven't. There's no room for I've done it, but I think I can drive teams to better conversations, but a misconception is that the definition of the donor is optional.

Jonathan: If somebody is interested, maybe they have just become, or they're interested in becoming an Agile team after having done something ad hoc, or maybe something water folly, what are the steps they should take to start doing scrum? How do you implement it? I guess you don't have 30 teams all do it at once. We know that's an anti-pattern, but what's the right way?

Jac: I think if it was me, I would get a blank wall. I would put the Scrum components in terms of events artifacts on the wall, and I would-- if you imagine there is some tracing paper, put what we do now at the moment over the top and see if there's a consistency. You may have a bi-weekly governance review. Well, could we invite the customer to that? Could we make that a bit more engaging and not into a sprint review? Maybe we do.

We look ahead every couple of weeks. Do we have an ever-growing list of requirements, a.k.a potentially called a product backlog that the team can see? I would get the recipe book that is Scrum, I would put that on the wall and see what we can align to at the moment. Also, the organization that I'm doing this product owner stuff for at the moment, still has a release cycle of four times a year.

Back to the technology debate. If we can only release four times a year, how does that fit into continuous integration and continuous deployment? Can we even start that conversation or are we going to be more process orientated for now? Which is fine, let's just be honest about it. If people are cautious, it's finding out what their tolerance throughout experimentation is.

Again, some people might not agree with this, but you don't have to go for the full 100% from day one. Should we start speaking to each other every day? Just for 15 minutes, to see if we're all on the right track, not to report in, but just to see how people are doing when was the last time we looked ahead? Should we put some refinement in and then not by stealth, because you want people to be on the journey, but I would say start with where the team wants to start because at the end of the day, they're probably the smartest people in the room as well and we need to start treating them like that.

Jonathan: I like that. What if you have a team that has a lot of ad hoc work, a lot of requests, and I'm thinking of course in this case of a DevOps or an operations team or a platform team. You get requests from other teams, you maybe get outage reports and you're doing a lot of ad hoc stuff. Is Scrum a good approach in your mind or some Scrum hybrid or something else? How do you approach that?

Jac: Off the top of my head now, I would probably say a true Kanban approach might be a better option. By Kanban, I don't just mean post-its on the board, I mean doing proper static, so systems thinking approach to introducing Kanban, really highlighting what the flow of work is. Yes, if I'm going to put my head on the table for this, I would go for a Kanban approach first for that particular [inaudible 00:31:28], but properly.

Invest the time into creating and amending the board that is going to work for the team. Are we looking at lead time, cycle time, throughput? Are we looking at limiting the amount of work in progress? Are we looking CFD diagrams, not just, we've got a Kanban board and we put some post-its on it, let's turn it into a real pool system using expedite lanes if we've got a major incident and things like that.

As time goes by, you might find that Scrum might suit your context better, but you could also say the same if you started with Scrum, you'll find out over time Kanban might be a better approach, or Scrum with elements of Kanban. If you're not building a thing that is going to be reviewed every couple of weeks, again, not everyone will agree, but I think doing good Kanban or introducing real Kanban would be a good start.

Jonathan: To make the question a little more difficult, now imagine you have a team that's doing elements of both. Maybe they're building a new database or something like that, that is delivered and so there's something that could definitely fit this Scrum framework, but they're also responsible for responding to incidents. How would you combine these two seemingly different responsibilities?

Jac: I think having a strong product owner would be key for this, just because the product owner has one priority. Technically, that doesn't mean it can always be fulfilled, so I would say product ownership in this instant and for a true team that you're describing would be paramount. I would be trying to work with them to make sure they understand what their responsibility is in terms of listening to the team, making sure they understand how to prioritize, what they're prioritizing.

Again, I would probably save your [unintelligible 00:33:40] and looking after the product Scrum with Kanban would be a fair approach. Maybe start off with Scrum. Like I said, introducing it bit by bit and then, okay, we're pulling everything from our sprint backlog into progress and it's quite hard to see the wood from the trees at this point. Shall we think about limiting the amount of work we have in progress in each color? That sounds like a good idea.

When was the last time we reviewed what the whole board looks like from a systemic point of view, but also keeping in mind, we are showing this off, we are showing the product or the new increment of the product to the customer in a couple of weeks, so we do need to keep that in mind. I think product owners and sprint goals and teams get confused sometimes by saying, "We're doing all of this work and it's all great."

Which is true, but having a strong sprint goal is saying, "This is the one thing we've stood behind for the last two weeks, but we've also done all of this other core stuff. We've deployed, we've fixed the number of bugs, the number of defects, we've cleared up some technical debt, but this is the one thing we're really going to stand behind." I think mixing the two is okay. How would you go about it, just out of my own curiosity?

Jonathan: Yes, I think I agree. I like the way the Google SRE book balances an engineer's time between ongoing projects, maybe it's a performance improvement or building a new system and responding to ad hoc requests. They actually will put a cap on how much an engineer spends on ad hoc requests because they recognize that that burns people out. If over a certain amount of time, over a month for example, you spend more than half your time on that, then you're removed from that queue and you don't handle any more ad hoc requests until that average goes down again. You have an opportunity to A, build the thing you're trying to build and B, just not get burned out and bored with all these requests.

Jac: I totally agree, yes. Capacity planning is seen as a dirty concept, but I think if the intent of capacity planning is to help those doing the work and that intent is kept and it's done with that in mind, I think there's nothing wrong with capacity planning, but because as long as it remains to help the team, there's no point ramping the team up to 100%, because we know they're going to be working at 150.

They've got defects to fix, they've got HR training to do, life gets in the way, the connection might go down. It's a difficult conversation to have with some people, but you have to explain it in a way that you have to mirror them. You have to explain it in language that they understand as well.

Jonathan: On the topic of capacity planning, what's your take on the whole estimates versus no estimates thing. I imagine it's nuanced because most of what you tell me is, but I'm curious to hear what you think on that.

Jac: It's difficult because some of the training that I do, I'm contractually obliged to talk about story points, but I always make it clear that I'm going to give-- This is what I have to do, but I'm going to make it clear my own opinion. My own opinion of it is they can-- Story points, for example, can be a good compass to see how far down the backlog a team can get.

I would use it as a compass and nothing more. Story points don't equate the value as many of the listeners on here will agree with, but some of the newer people to our community may not. I think there's a balance that needs to be had, where leaders in our organization are being asked to commit vast amounts of money on something, on an outcome or on a set of requirements.

We have to empathize with them as well, but I think funding teams and funding outcomes, maybe a better way and back to the point before of this whole Agile stuff goes so far beyond the engineering in terms of how we contract, how we bring people onboard in terms of procurement, but I think the flow metrics, so lead time cycle time throughput, which then can lead to the 85th or the 80th percentile of 80-- 60% of the time will do a task in six days.

That's going to tell a better story than saying well-- And I've seen contracts that literally say, we are committed to delivering 80 story points a sprint, but folks, what if that's story 80 points worth is absolute nonsense that no one cares about? I always say when you get an update on your phone, there's not many people who sit there and go, "Oh, I wonder how many story points that took the team?" They don't care.

I see both sides of the argument. I would say that story points can be a good comfort. They do generate a conversation. The conversation is more important than the number, but I think the flow metrics are a much better way of answering the question of when it will be done and the book title, when will it be done dives further into that. I would recommend that book.

Jonathan: Awesome. We'll put that in the show notes.

Jac: I'll send you an article by someone as well. It's a series of articles about better ways, better things, and story points. It's not mine. I just use it, so I can send that one as well.

Jonathan: Great check the show notes for that then. This hypothetical team we're on has decided to do Scrum. We've put all the current situation on a board or we compared it to what Scrum calls for and we started to see some overlaps in places where we can start to move towards Scrum. Do we need a Scrum master? Do we need a dedicated Scrum master? Do we need a PO? How do we answer these questions?

Jac: I think to get the benefits of the framework, I think the product donor would be a non-negotiable, but in saying that, product donor means different things in different organizations. If you're in a large financial organization and your [unintelligible 00:40:36] use a Scrum team, you'll have a product donor, usually the BA because they're with the team, but who's the real product donor? It's probably someone with layers and layers above in that organization.

Again, let's be honest. Are they the true product donor or are they a voice of someone else? I think to answer your question, having a strong product donor is a non-negotiable. I think having someone who is interested in helping the team and introducing this framework, whether that be a developer or whether that be, I don't know, someone else early on, will be a key point to make sure that the team are on the right train track.

I don't mean release train, I mean literal track. Whether they need to be full, I would say the full time at the start to make sure people are having the [unintelligible 00:41:39] about, well, what does a good sprint review look like? What does a retrospective look like? Are we using the daily Scrum as a status report or be a synchronization? I think it's probably harder for a developer to wear both hats sometimes, because if you think that the Scrum master more often than not, even though they don't have to, facilitates the conversation, I think it could be quite hard for someone who's very technically minded to pull themselves out of the solution because that's what they're passionate about.

I think there will always be a need for facilitation, whether that's a full-time person or someone who sets up one team, moves on to another, but always has an entry point to the team they left behind. I think a good barometer for a Scrum master is to say, "Well, is the team having the same problems they had three months ago?" Now, the answer's yes, some of that might be due to things outside of your control or you might have to put a bit more effort, I'm sorry to say.

I don't know if I believe that a Scrum master's job is to make themselves redundant, because I've just said that I think there'll always be a need for some facilitation or the option for facilitation, but I definitely think a Scrum master can move beyond the team that they start with either onto another team because I believe in pilot teams, so we start off with one team and move on, and then move onto things in your organization whilst keeping that area, that touch point.

Jonathan: Nice. What role does Scrum training or should Scrum training take if you're starting to adopt Scrum? Should you get a certified PO or SM or other trainings? Should you read a book? What's the best approach?

Jac: I've never done-- Is a spoiler. I've never done an official Scrum master course. I've done the certifications through scrum.org through my own learning, listening and things like that. I am a big fan of the Scrum master toolbox podcast, short, sharp 15, 20 minutes. That's how I learn a lot of things. I would say knowledge building is more important than training. Like I said before, having those smaller, more personal sessions of what does a sprint review mean to us as a team?

This is what the book says or the guide says and that's great, but I'm not really a big fan. It's difficult because I'm on a product workshop at the moment, but I'm not the biggest fan of the Sheep Dip approach in terms of, like I said before, that example, you send a couple of people on the two days Scrum course and then switched 30 teams on. I think it's the Scrum master's responsibility to keep it going.

Even if that's just a weekly email saying, "This is the difference between story points and flow metrics." Short, sharp snippets of information probably more important than training, but if someone wants to go on an official course, then I think they should be commended for that as well. It's a tough one. No one complains about PRINCE2 courses, do they? I think Agile is flavor at the moment in terms of all courses are bad.

In saying that, here's what I would do. I would look for the trainer. I would put more emphasis on the trainer than the course. I would look for someone I respect, someone who is pragmatic enough not to say this is the be all and end all. I would look at the stuff they put out online, LinkedIn, Medium, whatever else and I would pick a good trainer rather than be too focused on the course.

Jonathan: When does it make sense for this team we're talking about to seek external help, hiring an external consultant, maybe somebody like you or your company and when should they do it on their own?

Jac: I think they should always aim to do it on their own and I think the incoming consultancy has to set themselves up to leave. I think that's what I'm trying to build. I don't want people to be reliant on-- I've seen too many big companies who would be baggered for want of a better phrase, without external help in consultancy, but I think they really need to know what they're asking for. What specific problem do you need help solving?

If you don't know, let's spend some time hearing the pain points and I think an exit date is key and what you are going to hold that consultancy accountable for and what outcomes you want to see at the end and proper outcomes. Not like we want to train 50 people. We want to put 50 people through an introduction to Agile. Proper outcomes. The team's lead time, cycle time have decreased and there's different ways to measure it.

I know it's not binary, but the team's overall morale because has gotten better, their understanding has improved by however much ascent. I think the consultancy needs to be accountable and they need to start with the end in mind.

Jonathan: Well, I think it's a little bit refreshing to hear a consultant who says you should try to do it without me first. [laughs] You don't hear that very often. I commend you for that. I try to take the same approach too, when I'm working with clients. I try to give them all the information that I can, but if you need that extra hand holding, I'm there to help. You are too. If people are interested in reaching out to you to either consider hiring you to help with their transformation, or they just want to follow you on social media, how can they get a hold of you?

Jac: I just live on LinkedIn really. Jac, J-A-C Hughes. Yes, I look like this. You can't really miss me at all. It's [inaudible 00:48:24] with the ginger beard and ginger hair. I'm sure I'll pop up. Feel free to reach out.

Jonathan: Great.

Jac: Thank you. For me, it's been brilliant.

Jonathan: Awesome. Thanks so much, Jac. We'll follow you on LinkedIn. Thanks for coming and educating us about Scrum and all of the nuance involved. We'll be in touch.

Jac: Take care.

Jonathan: Cheers.

[music]