Nov 14, 2021
Ian Spence is the Chief Scientist at Ivar Jacobson International. He spends his time coaching the teams working on some of the world’s largest and most technically challenging endeavours - such as the Square Kilometre Array (SKA) project, building the world's largest radio telescope to explore the Universe - and working with industry thought leaders such as Dean Leffingwell, Dr Jeff Sutherland and Dr Ivar Jacobson to improve the art of software development. He led the creation of the OMG’s Essence Kernel and many of the most popular Essence Practices. He has many certifications the most prestigious of which is SAFe Fellow.
Social Media/ Website:
Ula Ojiaku: My guest today is Ian Spence. He is the Chief Scientist at Ivar Jacobson International and amongst his impressive string of achievements and accomplishments, he is a SAFe Fellow and an SPCT. Ian in this episode talks about Essence in more detail. And before we move on to the conversation, Ian will be running a Better Scrum through Essence course this November, 2021. And for you, our Agile Innovation Leaders podcast listeners, they are offering a 5% discount if you use the code AILP5OFF. Just go to ivarjacobson.com and search for the training. On to my conversation with Ian
Thank you so much, Ian, for joining us on the Agile Innovation Leaders podcast.
Ian Spence: Thank you for having me.
Ula Ojiaku: I’ve been looking forward to having this conversation with you. I've been to a couple of your courses, you know, the Agile Contracting course, as well as the alpha version of the Better Scrum through Essence. And each instance I had lots of aha moments and lots of learnings. But before we get to that, could you tell us a bit about yourself Ian?
Ian Spence: I’m Ian Spence. (I’m an) Agile coach and consultant, I've written some books, I've done various things. I'm a SAFe Fellow. I've worked with quite a few of the main figures. Jeff Sutherland, Dean Leffingwell. And I was with David Anderson, (Kanban man) last week. And of course Ivar. Over the years, I've spent as a coach trying to help people - sharing knowledge and getting good practice into people's hands so that they can master the basics of the agile practices and then use that as a foundation to then innovate and develop, themselves and their workforce. My job is to make others successful. That's what I like to do,
Ula Ojiaku: And how did you get onto this path?
Ian Spence: When I got around to the age of sort of going to university, at one point I was going to be a Civil Engineer, but then I discovered that very few of them actually get to build bridges. So that took the fun out of that. So I thought I'd like to know how to build robots. And this is a long time ago and there was one course on robotics in the UK. But robots are computers and control systems. So I did a degree in Computer Science and Control Systems Engineering thinking this would be computer controlled, but they're actually two discrete subjects in different buildings. I ended up with a degree in Computer Science and Control Engineering and I got a job as a COBOL programmer in Sheffield. My job existed to fund my musical endeavors at that time. And then I got too old for musical endeavors. So I wondered what would happen if I actually paid some attention to my career. And since then I've had some books published, become a conference speaker, worked on some of the largest, most complex projects in the world. I mean the Square Kilometer Array. I like to talk about them because one I'm allowed to. Most of the exciting things I work on - some of them nano medical technology I was involved in. I can't even talk up. I don't understand what it did and I'm not allowed to tell you, but the Square Kilometer Array is the world's biggest science facility ever built. It's a big radio telescope. It's in Wikipedia. They have a lovely public website and I'd been coaching them probably for three years now.
So they're developing the software for that using the Scaled Agile Framework and agile techniques. And that's the kind of software you build super computers for.
Ula Ojiaku: I wouldn't have guessed you had, any musical endeavors. And I'd love to know more about it. If that's something you're comfortable with sharing.
Ian Spence: Oh! That's all in the shady past now. The keyboard player in my band has gone on to be quite a successful electronic musician and producer, but it's all very niche market stuff.
So, it was fun for a bit, but that's oh, years ago now.
Ula Ojiaku: So, am I right in the understanding you were part of a band and did it involve, lots of tours and did you release any records?
Ian Spence: If anyone wants to do some archeology on the internet, you may possibly be able to find out the name of the band, but there's no music available. We were okay , we were pretty good, but we didn’t have that magic ingredient you need to be successful.
Ula Ojiaku: And what sort of instrument did you play Ian or were you the lead vocalist?
Ian Spence: Oh no. I was the guitarist - that's what I played
Ula Ojiaku: So how did you, arrive at IJI (Ivar Jacobson International) as the Chief Scientist?
Ian Spence: Well, I was a software engineer for many years, and I was one of the first people in the UK to learn Java. I wrote the first commercially available Java course in the UK. I was doing small talk programming. Got a job with a, consultancy, started doing a little bit of consulting and then unfortunately that company – the owner decided to shut it down. So we went and had some interviews and I had job offers to go and be a serious Java programmer, or to join Rational as a consultant.
So I started doing a lot of work or consulting around the Rational Unified Process. Met people like Dean Leffingwell when I was working at, Rational Software. Rational was a good place, but that got purchased by IBM. So, me and some of my colleagues decided this was an opportunity to leave. And then we sort of merged. Ivar was also leaving Rational and setting up a consultancy at the same time.
So we came together then. So I ended up as Chief Scientist at IJI.
Ula Ojiaku: So let's go on to, Better Scrum with Essence.
Could you tell us about the course and your involvement with the Essence standard?
Ian Spence: So a long, long time ago in a land far, far away, a group of people had started a new company and they had been doing a lot of work with the rational unified process.
Not surprising as Ivar was one of them. And we were looking at how can we, what can we do to make this more agile?
So we started looking at, is there any way we can have the practice be the first class citizen? So if you look at, Practices say like use cases as a practice, Ivar came up with that. It was the foundation for the Objectory process. It was in the Rational Unified Process. It was in lots of other processes.
Most of those have gone, but use cases is still one of the most popular ways for people to capture requirements. I mean, the term use cases actually entered the English language. So practices last a lot longer. Many of the agile practices, people think they're discovering as shiny new things have been around 50 years or more.
What we wanted to do was free the practices. So we did, something we called the essential unified process, which actually was made out of practices. And he thought this is a good idea, how can we make this more popular? So Ivar founded this organization CEMA, other luminaries, Tom Gilb, Hollister Coburn was there.
They had set some introductory meetings. They were quite successful and, donated the underlying language. Right? So maybe more people could do practices. Ivar loves to talk about the method, prisons and method wars, but (Essence is a way to) basically free the practices.
So the owners, the people who come up with a practice don't have to see their work rewritten, rebranded, recast every time someone built a method. So that teams can put together and plug their own way of working. And we've just been working on that ever since, so we’ve been trying to get a healthy, vibrant practice community.
And one of the biggest things that's happened for Essence in the last few years is Jeff Sutherland's involvement. So scrum is described in the scrum guide as you know, 19 pages or something, maybe a few (pages) less in the last version, very succinct, very accessible, very good. Lots of good scrum training.
And Scrum is in SAFe. Scrum is in LeSS, Scrum is in Scrum at Scale. People use Scrum in software, they use it everywhere. But if you look at the numbers over 50% of the people who say they're doing scrum are failing or doing it badly. So Jeff is very keen to find any way that can help people do better Scrum. Ivar and I went out to Amsterdam, met Jeff introduced him to the idea of Essence and he got the idea very quickly.
He liked the idea. And I worked with him to create the first set of scrum essential cards. And these have been around; they've escaped into the ether. Lots of people have them and use them.
But Jeff really liked the cards. He started using them in his training courses and he found that just as a simple, an active glossary, you can engage with, you can do lots of exercises.
He likes to play a game he calls build your own Scrum.
So he gives people the cards, but no context, and they have to assemble Scrum and a lot of the time, somebody on one of Jeff's course that he learned more in the hour, they spent doing that than he had in the last three years doing scrum. The idea is to bring practices to life
and make them more accessible and actionable to people. You know, having things on cards, isn't a new idea. People have done that for years, but there's a language and semantics behind these cards that allow you to compose practices together. You can actually execute the language so you can generate the task.
It's possible to generate the tasks from the Essence definition. If you want it to go down that route, there are checklists to help with quality. There's also the other thing we have, which we call the kernel, which is… ( holding a little card up to the camera). This defines what it entails to do software engineering, not how to do it, just the what, and that defines the methods space for software engineering.
So when you load up practices into the kernel, you can see where you haven't got anything where there's things missing. You can use it to try and get balanced between the seven key aspects identified in the kernel. So, you know, as you're building your solution, are you keeping your stakeholders on board?
Do you know what the requirements are? Have you got a healthy team? So much can be done with it.
The Scrum Essentials are literally a hundred percent aligned with the Scrum guide, but they bring it to life. You can interact, you can play games and you can say which bits you like, and you don't like. You can look at the connection.
So a really good aid for teams starting out, or just to refresh the Scrum - revisit what you're doing. A lot of people are using them and coming up with new games and ways to play them.
And the, the goal is there to be a viable set of practices. And then, you can pull them together. You know, a lot of teams mix Scrum and Kanban together. Wouldn't it be great if you could take David Anderson's Kanban practice and Jeff's scum practice and have the pieces there. so you could, you could see how they fit together, where they reflect, you could merge items together.
You know, I don't really care what you call the person who facilitates the agile team. You call it a scrum master. Do you call it a flow master? Do you call it a team coach, an agile coach? I don't care. What's important is that someone is playing that- has those accountabilities. Agile teams really benefit from someone who's looking, being the conscience of the team, helping them to improve.
Recently I ran some workshops at the SKA. Like I say, they're very nice, cause I'm allowed to talk about them. We used Scrum Essentials - one of the scrum practices we've developed with Jeff called the scrum accelerator to help their scrum teams within a safe environment, get better at Scrum.
Right? So you can take things from different places and mix them together and benefit from that knowledge. And that's, that's really what it's all about. It's a kind of Ivar's 'change the world' mission. We don't make a lot of money from the cards - we give them away for free, but hopefully it's helping people get better.
And that the idea of Essence will spread and every team will be able to pick up and play with the right practices and organizations will be able to establish the kind of common operating model they need. So they have a local vocabulary within their organization, but the teams can then pick up whatever practices are going to help them the most. And even organizations, if they want to, they could mandate some practices. Most companies mandate some financial and accounting practices, because if you don't, you might well not be a legal entity and things like that. Safety critical you have standards. So we can do all kinds of great stuff.
Quality checks, checklists, build life cycles. But the idea is to stop having these big descriptions of everything, which will never last because you know, which practices are improving change in new ideas all the time and have something where the way of working for the organization is as agile and as flexible and learning as much as the people in the organization as a whole.
And that's the end game. It fits very well with scrum, because to use a scrum practice, you've got to pick a load of other practices. You don't have to do user stories, you could do use cases or other stuff. And it works really well with Kanban because it's all based on the idea of evolution.
Ula Ojiaku: I’d have to say, having used the scrum cards that you've talked about, they are really very helpful and it does, I can testify in the sessions I've run, you know, with the teams, I support.
It kind of brings things to life and it just helps. They're not wondering, 'oh, what's a daily stand up. Oh, what's a retrospective', because the definition is there you know, it's clear for them to just read and do the exercises. And one of the things I'm also in the process of trying out is designing an exercise for a team that wants to maybe start adopting some scrum practices, but they are Kanban. kind of build your own scrum, you know, pull what practices you want and don't take anything else - no more, no unnecessary overheads.
I know that you have a (Better Scrum with Essence) course coming up. Do you want to tell us about this and what the, audience might expect to experience on your course?
Ian Spence: Well, as you mentioned, you went on the alpha course.
Ula Ojiaku: I was and I thoroughly enjoyed it
Ian Spence: So it's covers quite a lot, but I did one with Jeff Sutherland on Better Scrum with Essence. You (Ula) are one of the very select few who got to go on the course and the course is, basically it doesn't teach you Scrum and it's not an alternative scrum master course.
It teaches you how to use the scrum practices to play games. It covers sort of learning games, things you could use just to learn about Scrum. It covers, uh, how you can use the kernel to understand where you are. It covers the scrum accelerator and other games you can play to improve Scrum and it does cover some scaling stuff, how you can use some of Jeff's Scrum at Scale ideas, just to assess and play around with things. , you can use Scrum Essentials, you can use this with teams using SAFe -anyone, any scrum team, whether they're doing software can benefit. One of my colleagues is working at the Royal Navy, 30,000 people learning about Scrum
and he's been using the cards an awful lot too. And they're not doing software development. And a lot of it is hands-on because you start playing the games. Actually, the one we're going to deliver in November is going to be a bit longer so it's very much playing games, exploring things in your groups rather than being lectured. And a lot of the games are transferable to any practice, but it's particularly useful, given that we have the access to the Scrum practices that Jeff helped us develop.
So a great course for any coach, any scrum master, or any, we used to call people, call them process freaks. So if you're really interested in the ideas of Essence, this is a great way to, to learn the practicalities and how Essence would help you before you start going into the language and how to write things in Essence, but you know, people can produce their own practices.
There are companies out there who are using these ideas to document their own ways of working.
And it's interesting because the course would have been so much better if we'd been able to be face-to-face we'd have had so much fun playing the game. There would have been things stuck on the walls everywhere.
It would have been great, but it works well online. We use Mural boards and stuff. So when people leave the course, they've got the cards, they've got the templates. You can literally, the next day I've known people go and start using the stuff that they've learned so that that's great, but you can sit down and very simple in an unobtrusive way with a team, find out which bits of scrum they like which bits they don't like, which bits they're doing, which bits they're not doing and get those conversations started.
Um, I did it with a team recently. They didn't have any Sprint goals. And they didn't know anything about product goal, which was introduced in the latest scrum guide. So that uncovered that in a way that was sort of non-judgmental. And then we could talk about, well, you know, how do you think it would be useful?
Well, why don't you try having some things like that? You know? And if, if we say daily, stand up, we hate it. Well, there you go. There's a, there's a, that's straight away. You've got something to think about how to improve and it gets you away from all of the ‘mad, sad, glad’ and all of that. And you could be proactive. One of my favorite things is just, uh, in a retro pick a card and say, ‘well, how's this one going?’
So you don't have to look at everything just randomly pick one and have a discussion about it and see if we're doing it well, if we could improve.
If you were a new team, and you're coming together for the first time, Scrum is a great way to start building that team working.
Right. But scrum does not give you all the processes and practices you need, but some of them you'll have in your heads. Some of them, you can pull it and as you go forward, you might move away from Scrum that's fine. But if you start, if you don't do all of the essential things, then you're not doing Scrum - we're doing something else, but that's fine. It's Scrum-like as opposed to Scrum but at least everyone will know you've got this different. We can start to share those values and we can start to have stuff to build, to build out on that. And it's the same with, with other practices.
Essence is quite big in the academic community. There's a whole community of university lecturers, building courses, based on essence to teach software engineering and to be able to teach software engineering in a way that's independent of the practices, some of the management practices.
So they can teach software engineering and they can use scrum as a tool, but they get that nice separation so that people know what's going on.
Ula Ojiaku: There's something you said earlier on about, teams being able to choose their practices and evolve. And you said something that some people might find heretic, which is that, you know, as they evolve they might move away from scrum practices. Could you expand on that?
Ian Spence: Uh, well, there's two sides to this. If you, if you're doing scrum, you should be doing scrum.
Well, there's a lot of people out there blaming scrum and saying it's not working and they're not, they've never done it properly. They've always done some spray, you know… water, scrum, fall, or whatever. so it's nice if we can actually have meaning behind the words we use and the practices.
A lot of the time people say they're doing one thing as an excuse not to do another, right? But software development should be a profession. People should be professional. We should maintain certain standards. And if we say we're doing X, we should be doing X. But a lot of agile coaches are familiar with Shu Ha Ri. . This comes from martial arts and in martial arts Shu - you are studying the standard forms and you're doing them by the letter. And that's how you build your muscle memory. That's how you build your basics. And then when you get to Ri - you start to be able to mix and match the forms and adapt them a bit.
When you get to Ri - you have transcended. If you're starting out as agile, basic forms, you need to learn as a team, Scrum and Kanban. I think every Agile coach should have their Scrum and Kanban experience. They should have the experience of doing it. Right?
And, um, the cards are to help the teams get that, get that muscle memory. And then when you go up the levels, at some point, you might get to the Ri level and transcend that's when you, uh, that's when you can really invent new forms, that's when you can pick up the existing forms and put a twist on them, but it takes many years to get there.
And seriously, I don't believe there are any, any shortcuts. Right. And a lot of people seem to forget how they got where they are. Practices and frameworks are where you start even things like the Scaled Agile Framework. But for me, that's not an end point it's a starting point because if you're Agile, you're inspecting and adapting. So you have to inspect and adapt your way of working, right?
Now, the problem is with anything that's popular, many people have inspected and adapted it and broken it. One of my SAFe training courses, I did, someone came along from this major company and they said, well, the team have told me they're doing SAFe and she listened and she enjoyed the course and she went back and said, ‘you're not doing SAFe but you ought to be doing SAFe. So we're going to get these people to come in and help us.’ So I went in to do some coaching. Now, let's say I was told that there were eight agile teams . Now, the person who was like the lead agile person in the technical side of the organization.
‘What teams have you got?’ By the time they've got to team number 15, which is two testers working alone. They, they were so agile. They had self organized themselves out of agility. to get them go back again, they got put back into scrum teams and then we did the PI planning and they went and they actually delivered the MVP that they'd missed a date for three times before.
So it was a very successful adoption.
But what the practices do is they keep you on the straight and narrow. So master the form and then as you go up from Shu to Ha to Ri, you will be able to start adapting and inventing new practices. But you don't get to that state without going through the hard work of learning, the basic forms and the basics.
I have delivered, SAFe training with Dean Leffingwell. And I delivered Scrum at Scale training with Jeff Sutherland. And I've had some very, uh, interesting experiences where people on Scrum at Scale are trying to bash SAFe; they're more similar than they are different.
Your job, as a coach, isn't to rip the foundation out and say to people ‘you're not agile, you're doing SAFe. You're not Agile, you're doing that.’
What your job is, is to say, ‘Ah, you're doing great. What could we do better?’ And if we bring some ideas, what are the other frameworks in… Lots of great ideas in SAFe, lots of great ideas in Scrum at Scale, lots of great ideas in LeSS - you're looking to improve.
And, you know, if you are still doing those essential things from that framework from that practice at least you've got the commonality that people need to work as a large organization.
You can start to evolve and play around and then practices can move about . I see all the frameworks as a starting point. SAFe is brilliant for lifting and shifting large numbers of traditional people and making them all agile.
Ula Ojiaku: This brings me to a question really. You mentioned earlier on, , that organizations, potentially can build their own Agile framework from the ground.
Ian Spence: Um, well we have to be careful when we say Agile framework. An agile framework is a pre-constructed set of practices and a reference model to help organizations create their own operating model. So every organization needs, their own operating model and that could include mandating frameworks and practices, but everyone, you know, you get your competitive advantage by having your own way of working. All right. So as organizations evolve from that standard model, that's useful in many contexts and create the one that's working specifically, uh, you know, optimized for ourselves. And reflects our learning and our skills and our recruitment policies and all those things that are part of a healthy organization.
Ula Ojiaku: Thank you for clarifying Ian, however, would I be right in the understanding that what you're saying is for it to work, that has to be a shared language across the board as a fundamental…
Ian Spence: I'm going to do a conference talk in Russia called, um, Agile Horror Stories.
About how things go wrong. And one of the ways things go wrong is people take a challenge and blow it up and they start blaming other parts of the organizational structure. They'd start blaming all kinds of things for their inability to achieve the goals and outcomes that they had, you know. You don't have to change HR to go agile, but if you go agile, you can change HR to benefit things.
So you've got to look across what, you know, what's the scope, what, what's the challenge, what commonality you need. No organization needs to have everything defined in the same way, but there are, if you want to do, you know, effectively portfolio management across the piece, you need some things that roll up and down across the backlogs and stuff like that.
Then if you're going to go and talk to people, you need some consistent positions in the organization. So you know who you should be talking to, right? You shouldn't have to redefine the positions every time you changed the practice right. I did a talk at the SAFe summit a few weeks ago on the idea of the dual operating system.
Now, a lot of agile people - I've seen a lot of articles - they said, ‘oh, we don't need any dual operating systems.’ And what their people are showing is they haven't understood what it is. We want the agile, the value streams, which flow across our organization to work like a dynamic network. Self-organizing, self-determining we want that right now. Every organization, every human social structure will have a hierarchy in it. If you don't have a dual operating system where you separate the functional hierarchy or position in the organization, from the value streams on the network, the value is never going to have that beautiful unimpeded flow.
Ula Ojiaku: Yes
Ian Spence: What people are doing is they are not creating a network. They're creating a new hierarchy, right? And again, all these opposition are in pointless fights about stuff right. Now in the latest scrum guide they deliberately said, Scrum Master is not a role. It's a set of accountabilities. Basically, it's a card that someone picks up and goes, oh, I'm going to be the scrum master.
I know people who act as scrum masters, who are, very senior in an organization because they run their leadership team. They run their lean portfolio management group as a Scrum. I worked at the, Gibraltar financial services commission where they did scrum all across. This is the business of regulations. They're not software.
The first scrum team was the leadership team. And they were great. Every day, you'd see the CEO running to the daily stand up. It was brilliant. All right. And they were leading from the front, but you know, the person who was the, Product Owner for that group was the CEO and that's their position and that's their title.
And they took on the accountability of Product Owner for the leadership team. And they had someone who was a senior coach who took on the role of the scrum master for that. But she was mainly coaching all the other people in Scrum. She was a scrum master for that particular group.
So, you know, no, no changes of job titles. No, disenfranchising of people to start with, but yes, as you become more agile, you will improve everything, including the hierarchy. So yes, a lean hierarchy is better, but the big mistake too many people make is they create these sort of agile hierarchies and they do it and they haven't even dislodged the old one.
So now they've got two hierarchies. So it's like, we don't need a dual operating system. We've got four hierarchies already. It's just crazy stuff.
Ula Ojiaku: Some of the pitfalls you've mentioned, most recently being the one about agile hierarchy and multiple hierarchies instead of adopting the concept of dual operating systems in the spirit that it's meant to be, how can leaders in organizations, that have gone through transformations, recognize this sort of pitfalls and avoid them or remedy them if they've already kind of fallen into a rut.
Ian Spence: I mean, the whole leadership question is an interesting one, particularly with some of the political leadership we’re seeing in the world today. Um, but the, the idea of the leader that serves , of, uh, leaders who are empowering and delegating and stuff like that, um, is incredibly, incredibly powerful. So what leaders need is the agile mindset.
Now, when you're looking at practices, right, there are millions of scrum teams in the world.
So the higher up as a leader, the more it's about your mindset, your personal skill, you're not following practices. You're not doing routine type work in the same way. So what you've got to do is have that lean and agile mindset. Now, if you are leading a change, symbolic leadership is incredibly important.
So you've got to lead by example. Um, you've got to understand the, the mindset and the principles. You've got to focus on outcomes, the real business outcomes, not output.
You've got to learn how to use metrics and stuff like that, but you've got to go on a journey with your teams. You've got to do that kind of stuff. Um, And, you know, I've coached quite a lot of that. The biggest challenge I find when teaching, you know, leadership is something that you see at all levels of an organization as well.
So every agile team will benefit from some agile leadership. Coaching is not something that's only done by coaches. Every good leader will… certainly a good agile leader will have coaching capabilities… will be developing their people. So you've got to learn about, about that kind of stuff.
But the biggest problem I found when teaching, when coaching senior people say portfolio managers and stuff was basically just never turn up.
they're too busy and that's not good. Don't be so busy that you haven't got time to get better. So take time to learn, take time to do experiments, do new practices.
You've got to get into that. I mean, delegating authority is doing that. Doesn't mean I'm neglecting your own accountability and responsibility. So transparency and empowerment. Agility is there to empower leaders as much as the people being, led. And that's important. So all of these things can help you as an agile leader in agile, organization, you can be a better leader because you can really decrease the decision latency.
You can spend much more of your time. Um, looking forwards, planning, forecasting, steering, creating the buzz, the vision and less time looking backwards.
If you're learning to be an agile leader, don't get caught up in all the framework wars and all of that. It's about the mindset and about empowerment, autonomy, purpose, and all those, all those good things.
I highly recommend... there's a video they use in the Scaled Agile course. David Marquee, a model of leadership, the nuclear submarine. Yeah. Yeah. So if you don't mind, um, all male or military type examples. It's a great about that leadership by intent and serves the those things. So as a leader, let's become about leading rather than chastising and administering.
And management is incredibly important. Um, Google did some experiments where they tried to take a, we don't need no managers. They tried to get rid of the managers. Nobody was happy. So they bought them back. What they discovered was people like good managers.
And I would assert, and I'm probably not the first person to assert this, but I can't attribute other assert anyway. Um, it's better to work for a good manager in a bad organization than a bad manager in a good one. And if you've ever worked there, I know people who have their whole career has just been moving, following a good manager anywhere.
They went, wherever I go and stuff like that. And often they've gone to a bad company, but you know, you will be looked after because they have a good manager. So good managers develop the people and skills for sustainable organizations. They set the vision, they make the decisions quickly.
Um, they involve more people in that decision making, but they keep their accountability, they keep their responsibilities. They don't pass the buck…
Ula Ojiaku: If it goes well, it's the team. If it goes badly, the manager takes the bullets.
Ian Spence: Yeah. The best managers to work for barely take that much credit. they get the credit because they've created that environment for everyone else to thrive. And, and, you know, the agile mindset, if you look at the qualities that Google said, a good manager needs, and if you compare it to the, you know, agile mindset, agile values, stuff like that, very closely aligned, they haven't normalized the vocabulary.
People use the sport analogy and I'm a big arsenal fan.
And I'm a big Arsene Venga fan. He would empower his players and send them out to play. He didn't have rigid systems. Jose Marino was the opposite kind of manager, right. The opposite kind of coach. But they were both fairly successful. Agile leadership is not the only style of leadership.
Right? Many, many big things have been achieved by bad leaders, doing things I personally would consider unethical and stuff like that.
Ula Ojiaku: But the question is how sustainable is it? People don't remember what you do per se, but they will always remember how you made them feel when they worked with you.
Ian Spence: Yeah. There's stuff like that. But, um, I talked to David last week and he said that the, um, the longest living successful organization is the Roman Catholic church. Right. They go back thousands of years, and this is still the same organization and they have changed, changed considerably. But I wouldn't say necessarily of a particularly agile organization, they have quite rigid rules, but their leadership has, has, has learned and developed and listened to people and changed markets and all kinds of stuff over the years.
So lean and agile leadership… it's what a lot of our organizations benefit from and need. So in basic learn about it and hopefully you're going to very successful.
Ula Ojiaku: Where can the audience reach you if they want to get in touch with you?
Ian Spence: well, I'm on LinkedIn. And that's the best way to contact me personally. If you want to investigate the Essence stuff, or get a hold of the scrum cards or the other cards.
Then the Ivar Jacobson website. is the place to go. You can freely download that stuff and has articles about that, um, as well…
Ula Ojiaku: Okay. All right, many thanks. And could you remind us the date of your Better Scrum through Essence course?
Ian Spence: Possibly it's, uh, the 23rd of November.
And it's a online course and it will start at nine o'clock each day, UK time.
Ula Ojiaku: Okay. We'll have the Beatles and the show notes. So thank you so much again, Ian, for this. Do you have any final words of advice for the audience before we close this out?
Ian Spence: The only final word of advice is stay be a lifelong learner, relentless improvement. That's something you should be looking at.
So be, be curious, explore new things. Don't get you to let yourself get trapped in any of these, any of these boxes. And, uh, my other bit for the agile leaders is. If you are investigating agile, don't just allow it to clutter up what you say with more meaningless management speak.
Okay. Keep it, think about it's about getting good outcomes, creating healthy, sustainable team environments, getting the flow of value, watch out for the buzzword bingo.
Ula Ojiaku: Thank you so much, Ian. I've really enjoyed this conversation and I hope we'll get, to have you back on this, show some other time.
That’s all we have for now. Thanks for listening.
I’d love to hear from you so please drop me an email at email@example.com. Take care and God bless!