Rowan talks about Scrum, Agile and project management. This is a lightly edited interview transcript where he and Louis Taborda discuss what (if anything) these constructs have in common.
Rowan Bunning has a technical background in software development including both project and ongoing product development. He began his Agile journey in 2001 and is a pioneer of Scrum in Australia having become the country’s first Scrum Master in 2003 and Australia’s first Scrum Alliance Certified Scrum Practitioner (CSP) in 2006. He was hired as an Agile Coach by the U.K.’s most prominent Agile consultancy in 2007 and became a Certified Scrum Trainer® (CST) in early 2008.
Rowan is one of the most experienced Agile trainers in the region. This includes leading over 400 Scrum certification training courses in Australia, New Zealand, Asia and the USA. In 2019 he became the first Path to CSP® Educator in Australia to be accredited to offer the full suite of professional development offerings for Scrum Masters and Agile Coaches through to Certified Scrum Professional®.
Rowan has been engaged as an Agile Coach by many of Australia’s best-known brands in industries including financial services, media, health insurance, federal and state government, retail, manufacturing, building security and video gaming. You can learn more about Rowan from his LinkedIn profile.
Louis: I have here with me Rowan Bunning, who is a Scrum expert and trainer. Thank you for being here Rowan, I look forward to hearing your views on some heretical aspects of project management perhaps. I guess to start you off, how do you think Scrum and projects work together, or should work together? What are your thoughts on the compatibility of these two constructs?
Rowan: I guess Scrum gives us options to have projects or not have a project construct. If you look at The Scrum Guide™, it mentions the word “project” twice, and it mentions the word “product” I think 128 times. That’s a bit of a cue to look at this. I see almost two different worlds out there that are starting to collide more and more, especially in this sort of Scrum space. The project world and the product development world, and I’ve experienced both. I’ve had plenty of experiences with Scrum with no project construct, around what we’re doing and having it more driven out of a particular product’s development where you’ve got someone coming at it from an entrepreneurial kind of perspective. Maybe a Product Manager, maybe someone who’s in that area of the business and that’s most impacted. So as a senior stakeholder or someone who’s got a lot to win or lose from the endeavour, and them steering it directly is one of the big ideas when we talk about the business or the customer actually steering the development directly. And you know, to do that, it becomes a much more facilitative kind of approach that a Scrum Master, in the case of Scrum, plays in order to help the business engage directly with development and steer the development in quite a high agility way if that’s what’s desired.
Louis: Would you say that, in a way, the Project Manager role in that context is a kind of intermediary that could get in the way of the direct connection with the customers or product owners?
Rowan: Yeah, it’s an alternative pattern almost to the business or the customer steering directly the development. We’re talking about “disintermediating”, if you will, by not having an intermediary or not having a project charter kind of construct, a kind of agreement between the parties as to what we can expect for our investment or for the sort of risk reward perspective up front. Especially the scope and date contract, as we know, with an agile approach, it is problematic to fix those sorts of things. So, we’re looking at making trade-offs and we’re looking at actually steering in terms of value, and to steer in terms of value, it helps to have someone who understands the context around value; what does that look like for our context, for our product or for our business? And therein lies the need for a product owner type of role, right?
I look at this in Scrum training. It’s quite fascinating to look at the three Scrum roles and then take a perspective on what does a project manager typically do, and then allocate those activities- whatever people come up with across all of that – to the three Scrum roles. And what we’ve found again and again – and this is with thousands of people having done this exercise – is that these activities become a collaboration between all three Scrum roles. And in fact the least amount of overlap is with the Scrum master between project management and Scrum Master. The most overlap is with the Product Owner role. And you see quite a few elements coming to the team to own quite a lot of the day to day management, the self-management within the sprint.
Louis: The third role is of course the developer, is that right?
Rowan: The development team, yeah, and I guess that’s a role in and of itself in Scrum, right? It’s not individual team members, it’s actually team as a unit. So it reinforces that it comes as a team, as a whole team or not at all is one way to think about that.
Louis: So, do you think as many project management views of Agility now have it that Scrum or the Agile team needs a wrapper of project management in some way? Because, as I said, if you look at PRINCE2 Agile, and you look at the other Agile project management, including PMI, the team has not escaped management. And so there’s a view that, yes, that’s development, and they can do the iterations, etc. but we still need the business case and we need the higher level reporting. What are your thoughts on the validity of that in what you’ve seen?
Rowan: Yeah, good question. So just generally I can see this happening currently. Organisations are moving away from having a single individual in the role of Project Manager more rapidly and it’s much more widespread, I think, than moving away from projects in at least enterprises, at least in organisations that aren’t perhaps so long-lived product centric. It’s more in organisations that are long-lived product centric, this style of having long-lived product development, not having start stop projects with a clear start and end to them. That’s more commonplace, you might say, in those sort of product organisations. And so there are two different worlds there.
Louis: Yeah. So we have the question of whether the project construct is useful in Scrum and then whether the project manager role is useful.
Rowan: Yeah, two different things. And you know, I think that they have different speeds if you will, different degrees in enterprises and a lot of organisations in Australia and New Zealand where I work as well. I think a lot of the need for the project construct, the reason for it being still needed, and useful technique wrapping Scrum, comes from the way the organisation is structured, and how the initiatives are framed relative to the way the organisation is structured.
So if you take the perspective of an organisation that’s organised around the end customer, particularly the external customer perspective of what products and services you offer, then there tends to be a more natural fit for moving away from a project construct. Where we need projects is when we have to work across a number of different elements in the enterprise that may be cross cutting, across different products and services. So you can’t necessarily have a long term view, to have a product owner, or a product backlog – take a product centric view. Because you’re saying we’re going to do this initiative that cuts across all of those different areas or different business units or different sort of capabilities within the organisation.
Louis: So in some sense, the complexity of the organisation might demand something more of Scrum?
Rowan: Well, it’s how it’s organised I would say because another way to actually address this – for instance, where a compliance, or regulatory requirement that cuts across multiple different products or service areas – may be to have Product Owners and product backlogs within those different products and service areas that actually look after the compliance issues that apply to them. And have reuse and opportunities to communicate across those different endeavours. but it is managed within those products or service areas. Which is a different thing from setting up a temporary project construct that runs across those different products or service areas, in order to deal with that regulation.
Louis: It’s interesting. The project as a temporary entity, versus the product as a more permanent and therefore worthy of organising around. It is as you say totally opposite views, one is for the focus of the immediate work that needs to be done – that’s the project, and the other is for longevity and efficiency, which is what a good Scrum team, an Agile team can build-up.
Rowan: Yeah. And I think that there’s a lot of benefits from having the longer term perspective, you’ve had a say on this. Just to touch on a few very briefly, your products and services – typically the ones that I’m running into are knowledge work and technology, software centric sorts of things, software heavy – they are being used all of the time, and there’s change in terms of our understanding of how customers are responding to those things. There’s change in the marketplace. There’s change that’s happening on different timescales, including change which can be quite urgent and all these sorts of things. To accommodate some of those changes that may be quite urgent and have to wait until a whole budgeting period can ramp up or the business cases can get approved and the portfolio can come to the top when you’ve already filled up a year’s worth of portfolio or pipeline or can make commitments on a longer term scale. That’s the sort of area where we see the general struggle for any sort of business agility, you might say. It’s a bit of a batching problem, you know, that goes right back to the way things are budgeted for and the portfolio’s managed and things like this as well. But just the idea that instead of having to wait until we go through that whole business case approval, budgeting, go ahead in the portfolio, to actually say, well, there already is a set of standing teams, there already is a backlog, there already is a Product Owner and something that comes up today could be actually actioned in two weeks or four weeks’ time, rather than having to go through all those sort of gates.
Louis: So one of the things I’d like your opinion on is a Dilbert comic, where the pointy head manager says, I need a project plan for this activity and Dilbert in the next frame says, “It’s done”. And the project pointy head manager says, “Yeah, thanks, that’s great. Now, could you do the project plan?” So in a way, it’s time constants, right, as you’re describing. I mean, in organisations, it can take a long time to get a business case up and to get all the approvals and that seems to be the competition between a software team and a group of people being able to deliver versus a managerial hierarchical process of approvals, etc. That seems to be the race in some ways.
Rowan: Yeah, I think in the big picture that’s one of the big differences I see across organisations where some have got the former, and some have got the latter in terms of those two different models. One or two other reasons, for the longer-term view. One is knowledge acquisition and retention perspective. If you think about knowledge work, the lifeblood of it is knowledge. A lot of what we’re trying to do when we do any sort of project, or any sort of product development, is to acquire knowledge about the right formulation of the product, or the right fit solution it – fit for purpose. And acquire knowledge about how pull that off and how to deliver that successfully. Because that novel, and different to what we’ve done before, a lot of what Scrum is based on is how we can acquire that knowledge and how we can actually share that knowledge and benefit from that knowledge. And delivery is almost a downstream thing from the knowledge acquisition – it is almost secondary to getting the knowledge and figuring that out.
So, if you talk about having knowledge, it helps to have people stay with that product long term and not just necessarily throw a bunch of people who might have the technical skills but know nothing about the domain onto it. Or have people that know a lot about the domain but don’t have much understanding of the technical possibilities. I’ve seen a lot of very good benefits in having people work in that same space for some years.
Louis: Now, when you say that though, it gets interesting to me because, relating it to projects, projects start and stop and when the project team goes home there is an implicit assumption, at least in product development, that somebody stays on to maintain the darn thing and keep it alive. So this agile approach and this ongoing team just blends the two, right? It says there is no stopping, and therefore there is no project. The team that stays the life of the product.
Rowan: Can be, yeah. Or, a small set of products that they move between – or a more broadly defined product which might have what we thought of as products as a number of sub-areas within that product. If you think about what are your customers or external stakeholders think of as what you offer – your products and services – then that starts to look at a broader, bigger picture of the products with and moving around them, certainly, maintaining what you develop.
I’ve had a client who had this product construct around their Scrum sprints and we went live with a new offering and there was this acknowledgment that well ‘wow’, this is now the first chance we get to learn about how our customers are reacting to that new offering, we’ve just released. Too bad we don’t have any opportunity to do anything about that, because this project’s ending now. Right, and we don’t have funding to do any more work in it. We hardly have people to maintain it, and if they maintain it, they’re just keeping it running.
Louis: They should have got it right first time.
Rowan: Yeah, and it puts a lot of pressure on that. And the more pressure you put on that, the more time we want to spend on analysis and design and being very thorough about those sorts of things. The more pressure there is to add more scope because we only get one shot at it, we may not get back to it till another year down the track or something like that. So there’s a lot of these dynamics that I think are important to start looking at in an organisation. Because they said, this is the first chance we have had to iterate. This is when we can iterate with knowledge of the customers’ feedback. It’s too bad that we don’t have a way of working that accommodates that.
Scrum for IT and Non-IT Products
Louis: You’ve had lots of people go through your training. And you’ve talked about knowledge and products. How many of them would you categorise as coming out of IT – roughly as a percentage. And how many of them are maybe more interestingly from non-IT? What have you found in your classrooms?
Rowan: Yes, it has changed over the recent years. It certainly, historically, was predominantly IT software development, within that, you know, pretty much exclusively to start with and it’s become an increasing proportion of being IT outside of software development. There are people who are more in infrastructure or maintenance mode or different sorts of aspects of IT, and increasingly now, people outside of IT altogether. And this is where I need to ask questions to understand what sort of domain they’re in and it can be more sort of business projects or business process looking at uplift in operations or some sorts of reform to the way the businesses is running and things.
Louis: So business has change as opposed to just software?
Louis: Any marketing types?
Rowan: A bit. Yeah.
Louis: And then I wonder because they, in some ways, have always done this, not Scrum but these collaborative, small teams, maybe not lasting for a long time, but having this intense collaboration.
Rowan: Yes. And I think one of the things that benefits in that sort of space, too, is being able to have fine grained cause and effect relationship identified between what you did in a campaign or some sort of action you took and whether that’s actually having an impact, isn’t it? Is the audience reacting to that? Are we actually getting clicks? Are we getting social media kind of results?
Louis: And it’s interesting that you used that analogy because of course technology is now a key element of marketing, as soon as you look at Google Ads being such revenue generators and a large part of marketing campaigns.
Rowan: Yeah, exactly. And I think this is an area where we, by doing things in fine grained ways – small releases often, small bets often – the sort of approach with marketing as well as with things.
Rowan: Yeah, exactly. We can start to say what pays off and what doesn’t pay off because, ultimately, again, it’s a complex space we’re talking about with people, human beings reacting to things where certain things may pay off in ways that you can’t anticipate and you don’t know what’s going to be a real winner, and what’s going to be a bit of a dud.
Louis: Again, going back to that decision making of the business case and having to invest a large lump sum and have to gamble on an outcome. In a way this is the opposite, as you say. It is making small bets and you’re continuously refining the criteria for the bet, and what you’re betting on.
Rowan: Yeah, I’m glad you picked up on that. Because that’s something I’ve been wanting to say. More often it’s a sort of mindset shift really, for stakeholders, executives and things like this. We’re moving into, as we’ve been talking about a lot of the world these days, the whole volatility uncertainty. These sorts of things mean making those big bets not so frequently, it isn’t necessarily successful. When there is uncertainty we need to pay attention to (it) and by having small bets often, we can have a low amount of exposure to things that don’t pay off and we can actually double down on the things that do pay off.
Louis: You can always learn as you go.
Rowan: Yeah, and cause and effect we can relate that more easily. If you do a year’s worth of development work and release 76 features out there and it’s kind of mediocre in terms of it seems to be some things are useful, some things aren’t. It’s hard to unpack that and go what parts of this were actually useful and compelling for people and which parts weren’t? Whereas releasing frequently, and I’ve worked with organisations that are releasing every day, they’re actually able to track within three days enough customer behaviour that they can actually see how people are responding. They get statistically significant data on how their bets are paying off. Down to that daily kind of fine grained level essentially and come the end of a two week sprint they can say well here’s how our customers reacted to the multiple releases we’ve done this sprint. What business decisions would we like to make based on the customer’s voice? Not just our internal kind of thinking but, our actual end customers.
Louis: It is interesting how the thinking is so recent. I just was reading a review of a book on Facebook, and how when they first put out the newsfeed feature, which today is the homepage of most people, right? But before that, before the newsfeed or just the static pictures, the profiles of individuals, they put up the newsfeed. And they had no idea, to go into this kind of iterative approach to this, they had no idea how people would take to it. They thought it was a good idea and they, in fact, got massive pushback because it seemed to be exposing intimate details. I changed my profile and people weren’t ready for that openness. But yet, a bit like Steve Jobs and all, Mark Zuckerberg pushed through with this and the development team pushed through with this. And by watching that, even though people complained, they were actually looking at the news feed all the time. So the evidence was opposed to the immediate emotional reaction, so the people complaining were even the biggest users of it. And so of course, now it’s the norm. So feedback is so integral to getting an idea right.
Rowan: Yes. And leveraging all sorts of feedback, the qualitative as well as the quantitative, and trying to interpret it is one of the big challenges isn’t it? Like that example shows, some initial indicators might give you a false read of what’s really going on and that’s why sometimes it takes someone reasonably savvy in this space. Steve Jobs is a classic example of someone who seemed to be able to interpret how people worked and how the psychology of dealing with computers and dealing with devices work for people in ways that anticipate needs that hadn’t been established yet.
Louis: And that’s what you can do if you’re watching your market rather than just doing big requirements-based initiatives. It’s the intimacy of your connection with the market, your customer.
Rowan: Yes, exactly. And just to tie that theme back, I think one very common thing I’ve experienced in very project-centric environments is everyone working in the project is very, very focused on finishing the project, or the delivery that the project results in. Especially if it’s one big delivery at the end, “one hit wonder” style. And every time we’ve focused on delivering that project, or that output, what we’re not being focused on is the customer and their reaction to it. And what we’re not being focused on is the outcomes and the whole benefits realisation which is often a secondary, disconnected exercise potentially from the delivery of the project itself.
Louis: It makes people myopic and lose sight of the ultimate goal – the outcome. The finishing line.
Rowan: Yes, and that’s exactly one of the things I talk about in Product Owner trainings, for instance, trying to get the conversation away from just output, output, output. What scope are we going to get delivered by what date? It’s very much output focused conversation and, really, how do we know exactly what output is best to work on to actually achieve the outcomes we’re seeking? Let’s elevate the conversation to what the outcomes are, how do we measure those? And how can we get a read early and often on are we actually getting towards those outcomes? And perhaps the aim of the game is to produce the minimum amount of output in order to achieve those outcomes, not just to do all the output we thought we should do up front.
Louis: You and I’ve talked about this, the limits of Scrum, which is focused around a team being productive and pointed at the customer. These new scalability issues that have arisen with examples like SAFe, the Scaled Agile Framework, and I know you’d support LeSS (Large Scale Scrum) and we mustn’t forget the Scrums of Scrums. What are your thoughts on the need to scale Agile, particularly Scrum? And how have you seen it done? What are your thoughts?
Rowan: Yeah, so obviously a big hot topic and I think when we talk about scaling, what are we scaling? Are we scaling just in terms of number of people working on something with coherence? Are we talking about scaling values and principles across the organisation? There’s different aspects of scaling.
Louis: It’s true. IBM, for example, I shouldn’t probably name names, was a big example of scaled Agile work. But it ends up everybody’s a development team, everybody’s software, their product is software. And, of course, their organisation is a software organisation. So scaling in that environment is totally different to scaling in a place where there is marketing, legal, a whole lot of other disciplines, that have to be wrapped up along with the technology.
Rowan: Yeah, so generally in this space when you mentioned all these different scaling frameworks, one thing that’s clear to me is that there’s different outcomes or different biases in terms of what those are designed for achieving. If you look at something like SAFe, there is talk about programme execution, managing of that PI or programme, level is the key thing. And it seems to be the ability to actually execute on what people are setting out to achieve in particular PI is a key thing for a lot of people in that space. If you look at LeSS, that’s looking much more about agility, which is not just faster, it’s about changing direction, manoeuvrability, being nimble, being adaptable, and having the ability to be adaptable, “turn on a dime, for a dime” sort of style. Plus be able to work in pure customer value order, which isn’t the case structurally if you’ve got a lot of component teams, and you’re essentially having to sequence things in order to deal with the dependencies between those different groups of people essentially, which means you’re not able to work on exactly what would be optimal for the value perspective. You’re actually doing things because there’s teams that are not able to do anything otherwise, because they would be essentially idle. Some people would go, well, let’s have them do something even though it’s not the top priority. Let’s continue them on the thing that they can do.
Louis: So it depends on the compromise that you’re trying to do?
Rowan: What are you trying to achieve? Yeah, exactly. Which goes back to the why question. Why Agile? What are we trying to get out of this? And I find quite a lot of organisations seem to have a pretty fluffy or vague kind of notion of this. I’ve been doing surveys for the last year or so, across a whole number of groups; private courses, public courses, conferences, all sorts of things and predominantly the answer that comes out as to why Agile is “faster to market”, “quicker”, this sort of thing. And, if you look at the flipside of that, that can for some people be more efficient just to deliver the same thing we would have delivered just more efficiently, or at a lower cost and these sorts of things. Whereas if you look at what the co-authors of the Agile Manifesto were talking about, and motivated by and inspired by, it was actually more about adaptability. They almost chose the word “adaptive” rather than agile [ed. as in the book by Jim Highsmith].
It was only because Jim Highsmith had that name already that it wasn’t taken up. And also because a guy called Mike Beedle, who sadly passed away recently, had read a book which, at the bottom of it, if you look at it, says “over 100 examples of agility”, which was published in the mid 90’s, and talking about organisational agility in the marketplace. And actually as a form of competition, a way to actually compete, not in terms of cutting costs, not in terms of just faster doing what we always did, not cheaper or anything like that, but actually being more adaptable, more nimble and able to deal with uncertainty, able to deal with change. And not just in the small but in the large. So what that book was talking about, and some people have called business agility generation three or four. Mike Beedle, but it’s basically virtual competitors is one of the things on the front of it. I can look it up for you later if you like. I always forget the name itself, but it’s a really interesting read. It actually characterises what they mean by agility in a very colourful way, and in a sort of way that I think still a lot of organisations haven’t cottoned on to is, in an environment, which isn’t just the mid 90’s. This is 2018 where we’ve got disruption in industries, we’ve got an awful lot of interconnectedness and uncertainty and change going on, that the ability to deal with that, to have not just a robust approach, but a resilient approach is a very powerful thing. More so these days than it was when this book was written.
Louis: Indeed one of the books that I remember Jim Highsmith sort of adapted approach, which was very biological, their metaphor was biology and being able to survive in this jungle of things changing and picking you apart. I remember one of the books that used to be almost recommended reading around that time is to Surfing the Edge of Chaos which is all these things of how does a product team negotiate all these threats and pick their path and survive longer term. You’re right. That’s kind of lost in terms of just being more efficient and doing what you did yesterday in a different method.
Rowan: Yeah, and just generally, I think a good schooling in this (it’s not the case for everyone who gets the opportunity for this) is to work in a space where it’s a brand new market or a brand new product offering or a quite edgy R&D kind of space, where there’s a high innovation to do something which is quite novel and quite disconnected from what we’ve done before. And when you start to see some of the risk/reward management in that sort of space and the way that we need to tackle that sort of space where we can’t predict it from the outset, we need to be able to work with a lot of emergent information, a lot of uncertainty as we go. I think if people have at least one experience in their careers that demonstrated that at a more kind of extreme level, if you will, it’s easier to sort of understand now how they could be benefit in perhaps less aggressively, ambitious or innovative kind of environments too. Or at least some of those ideas could be applied to spaces which are less about a new market offering or product offering, but about dealing with complexity with stakeholders or complexity with technical challenges or complexity with the marketplace just moving around on us as we work and things. So, yeah, I think that and also potentially working as an entrepreneur or closely with a fairly entrepreneurial sort of person, I think can help us see some of this style of working too, where you can see the risk/reward and see how an entrepreneurial kind of mindset of juggles that.
Louis: Actually you reminded me of one danger that I know I possessed when I attempted to be the entrepreneur, and that is a risk often stated of Agile that you iterate, but you don’t convert. In other words, your idea of what you want changes constantly so the team is struggling to get a coherent deliverable. Is that a legitimate issue and are there any techniques to avoid that or is having a bad sponsor product vision going to always be a problem?
Rowan: Yeah. It certainly can be a problem, and you just mentioned it. Having a coherent vision and some alignment around a vision, and having a vision as a shared vision and working at that is a very important thing in this space. So a lot of what we’re trying to do is delegate down or have decision making happen in a quite rapid sort of way, where we don’t need to go up a big hierarchy, or consult 50 different stakeholders to actually come to a view on what to do next. And that was aided by having context and having people trying to make those decisions and people closest to the information of what’s just come up, what the technical challenge is or what that feedback is from a customer, whatever it is, having the context to be able to navigate that without having to rely on people, very sort of arm’s length with things who actually understand the context. So, yeah, we need to work at that vision. And also, how do we look at more business outcomes that were measurable. Or things that are a little less concrete, but you’d at least be able to be clear about what those are. How do we judge what it is that is going to be successful of all these outcomes? And having everyone in on that is think is a really important thing.
Louis: We’re going to wind up but I just wanted to ask you, as I try and ask for my students sake, for a couple of gotchas that novice, usually I say Project Manager, but in your instance just a team of reps, what kind of gotchas have you seen that pop into your head that are avoidable with experience? What percolates to the top of your mind in terms of rookie errors in Agile Scrum or even just projects?
Rowan: Yeah, I think a big one is to not just look at it as a thing you do as a set of practices. There’s reasons why people are so big on the term “mindset” these days, right? Very fluently or efficiently doing the wrong thing isn’t necessarily getting you anywhere. How do we even judge whether we’re heading in the right direction with our adoption or with this change we’re bringing in, with these practices we’re implementing? Are we doing them in a way that’s actually directed towards the right sort of outcome in terms of what sort of performance characteristics we want of this organisation or what sort of payoff we want from Agile? I just think having that conversation about the why is a really important one. The more I’ve seen goalless Agile adoptions, you might say, where people are doing it for pretty flimsy sort of reasons without a clear picture of about what that North Star is, or what’s that vision for improvement is, or what’s the performance characteristics we’re trying to achieve? It can just end up in a lot of going through the motions, be doing the practices by the book, or quite well but still missing what gives you the biggest payoff. You’re sort of working around the edges doing some of the things that don’t give you the best bang for buck, the payoff from the whole thing. I think, there’s that and really, part of what I’m saying there too, is to have a bigger vision about where you’re going with Agile adoption, or any sort of improvement.
Really, I think there’s a lot of transformations, I guess that people could use that word transformation, when it just seems to be a fairly finite kind of change of state where we go from A to B and we’re restructuring and we’re just getting some teams up and running or something like that. And then suddenly, we’re “transformed” and that’s the end of it, right? It seems like we can declare success and go home sort of thing. And then I’ve seen with that sort of approach, how the energy just dissipates, things return. There’s the organisational gravity of things we haven’t really solved properly and there’s underlying incentives and reasons why people tend to fall back on things that are less aligned with Agile and potentially go backwards a bit to what they did before. So what we’re missing there is not the longer term vision about where we want to go as an organisation, but also the continuous improvement mindset and philosophy and culture.
Louis: It goes back to your comment about being at the edge of the unknown. I guess even in transformation, organisations should take that view of constantly tacking and tracking based on where the next benefit improvement can come from rather than just arbitrarily saying, we’re done now. We’ve improved. We’re level five.
Rowan: Yes, exactly. And, I mean, what’s implicit in what we’re saying too, is we actually need some time and space to actually invest in learning and improvement.
Louis: And maybe that’s why it always ends. I guess the powers that be, that’s a budgetary line item that they’re looking at.
Rowan: Yeah, pretty much it seems to be just the pedal to the metal to deliver, deliver, deliver. Yet if we want more Agile characteristics of that delivery everyone benefits that are different to what we’ve got now and the current status quo organisational system, well we actually have to invest in improving.
Louis: We’re talking culture in a way. Mindset, culture – these are things that are the intangibles that get overlooked so easily, right?
Rowan: Yes. I think one of the more insightful TED Talks I saw recently, you might know the one, was about looking at the performance zone versus the learning zone, right? And how we spend an awful lot of time in the performance zone in organisations and just performing within the current capability. And we starve ourselves quite often of the learning zone and having some time to actually experiment, to try new things, to have a more sort of “safe fail” to push outside of the current status quo capability to actually build that capability and then take those learnings back into the performance zone and get payoff. This is the thing that I think a lot of people miss out on, is just the idea that these payoffs are cumulative. It’s not just a one off thing, especially if you’ve got a longer term view of things that we could get a 5% payoff here, a 10% payoff here, this is 5% every month, 10% every month. This is benefits that can accumulate and stack on each other and make people’s work lives better, but you can actually do better things and achieve more without as much difficulty and without the organisational system constraining things to the degree it does now.
Louis: It goes to an implicit, shall we say, feature of Agile which is caring for people, right? I remember someone saying that the worst thing that Scrum ever did was use the word sprint, because it implies somehow that everyone’s sweating bullets, and will continue to do so every sprint, but the attitude and the underlying value to the mindset to keep this continuum going is the best in your people to have work life balance, that was a word back then, but just to have this culture of where everybody’s enjoying what they’re doing and there’s creative processes taking place.
Rowan: Yeah, there’s certain things you can only give people if they’re genuinely volunteering it or genuinely caring for it or genuinely caring for it, or genuinely putting their full selves into it. I think that’s important to understand in any sort of work with human beings is involved, not just to think of it as a machine where we demand something and people are obliged and crank out the same level of performance as if we actually have people feel that they are volunteering and they’re seeing a sense of purpose and the intrinsic motivators.
Louis: It’s a two way street, right? I mean, if somebody is working to live (not living to work) and clock watching, then it’s very hard to get them into an agile mindset because they’re actually very happy in the machine bureaucracy of the past. Because they’ll check-out happily, they don’t vest any of their emotional energy into the team. Have you found the wrong people in the agile, playing agile as opposed to being agile?
Rowan: I think there are definitely people that kind of had that attitude and are doing things to pay the mortgage, to just get by. I think one thing I have seen, and I’d like to see more of this really, is those people sometimes have a bit of an epiphany when they actually see others demonstrate, lead the way, to actually put more love into it and put more care into it and see a stronger sense of purpose. Now when we have a more compelling sort of shared vision, and we connect people more closely with the customers and actually go meet real customers, we’ll actually get some real smiles on the faces of the stakeholders. It makes it real. It’s now no longer just a bunch of tasks I have to do to get paid. It’s now “Oh, yeah, this is a rewarding thing to do for other people”. And, what would I prefer in life? Would I prefer to come to work and just do what I’m told, or would I prefer to actually see the real outcomes and the real payoffs and feel like it’s rewarding, satisfying, some of that sense of satisfaction. So I think that’s possible with people that may not have had that mindset. Not saying it’s easy to shift that but I think at least we can give people the option and try to create an environment that’s conducive to that and see if we can just turn up the knobs on that sort of thing for people.
Louis: Any last things you want to say that I’ve missed completely?
Rowan: I’m pretty happy, no. Thank you for the questions.