Jon Smart, author of the book Sooner Safer Happier: Patterns and Antipatterns for Business Agility, discusses patterns and anti-patterns for the success of enterprise software projects. Host Brijesh Ammanath speaks with him about the various common patterns and principles needed to survive and prosper in the digital age. They discuss why doing an Agile or Lean or DevOps transformation is an anti-pattern and how the focus should be on outcomes rather than outputs, and why psychological safety is the number one factor in building high-performing teams. Jon goes into depth on the need for a mindset change and why transformational leadership is required for leaders to coach and guide teams on this journey.
Show Notes
- Episode 420: Ryan Ripley on Making Scrum Work
- Episode 401: Jeremy Miller on Waterfall Versus Agile
- Episode 238: Linda Rising on the Agile Brain
- Book – “Sooner Safer Happier: Antipatterns and Patterns for Business Agility” (https://www.amazon.in/Sooner-Safer-Happier-Patterns-Antipatterns/dp/1942788916).
- Website : www.soonersaferhappier.com
- Amy C. Edmondson, Author of book – The Fearless Organization (The Fearless Organization)
- Eliyahu M. Goldratt, Author of book – The Goal (The Goal (novel))
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Brijesh Ammanath 00:00:16 Welcome to Software Engineering Radio. I’m your host, Brijesh Ammanath. And today my guest is Jon Smart. Jon is a business agility practitioner, thought leader, and coach. Jon is a lead author of the award-winning and best-selling book, Sooner Safer Happier, Patterns and Anti-Patterns for Business Agility. Jon previously was Global Business Agility Lead and partner at Deloitte. Prior to this, Jon led Vaso working globally for Barclays Bank. Jon has been an Agile and Lean practitioner since the early 90s. Jon is also the founder of Enterprise Agility Leaders Network, a member of programming committee for Devs Enterprise Summit, a member of the Business Agility Institute Advisory Council, a guest speaker at London Business School, and speaks at numerous conferences every year. Both me and Jon have worked together in our previous roles, and I have also reviewed Jon’s book. Jon, welcome to Software Engineering Radio.
Jon Smart 00:01:09 Thank you, Brijesh.
Brijesh Ammanath 00:01:10 We’ll be talking today about patterns and anti-patterns for the successful delivery of software in enterprises based on Jon’s book, Better Value, Sooner, Safer, Happier. We have covered Agile and Enterprises previously in Episode 420, Ryan Ripley on Making Scrum Work; Episode 401 – Jeremy Miller on Waterfall vs. Agile; Episode 238 – Linda Rising on the Agile Brain. Let’s get started with the session by understanding the drivers behind writing the book. Who was the target audience for the book and what motivated you to write the book, Jon?
Jon Smart 00:01:45 So thank you, Brijesh. The target audience for the book is leaders at all levels in all roles. So, it’s very much aimed at people working in large organizations looking to improve their ways of working and not only people in technology, not only software engineering but also outside of technology or people with no technology background. So, as much as possible, the goal is to try to use plain English and minimize the use of language that might be perceived to be jargon. And in terms of what prompted me to write the book, I’ve had, I think, speaking of the DevOps Enterprise Summit, knowing Gene Kim and then talking to Gene about the book writing process, it was, I don’t know, it was just like an aspiration I had to and a bit of an experiment to write a book. And I think being in that DevOps Enterprise Summit IT Revolution community, there are a number of people that have written books and Gene running his own book publishing company. So, then I had a conversation with Gene, Hey, what does it take to write a book? And then next thing you know, two-and-a-half years later there’s a book.
Brijesh Ammanath 00:02:53 Thanks. I think it’s pretty clear to me and the audience on the drivers for writing this book. And I know in your book you talk about better ways of working in the age of digital and the focus shifting to outcomes. What do you think has driven this change?
Jon Smart 00:03:06 So in Sooner, Safer, Happier, we are absolutely advocating a focus on the outcomes first and foremost. And the anti-pattern here is where organizations do an Agile transformation, where it’s all about the A word, it’s all about Agile. Agile is not the goal, the goal is something else. The goal is quicker time to value, quicker time to learning, more engagement with colleagues, higher levels of engagement, happier customers. So that this is the key, my key learning, with the lesson I learned the hard way and the mistake I made when I started out leading ways of working across a large financial services organization with 80,000 people. We were running an Agile transformation. We were measuring the wrong things. We were measuring how many Agile teams and so on, how many people have been trained in Agile. But that’s not the goal. The goal isn’t to do Agile, hence the language of better value, sooner, safer, happier, which is quality. Better is quality, value is value, which is unique, sooner it’s time to value. Safer is Agile, not fragile. And happier is happier customers, colleagues, citizens, and climate. So, really what we are coaching organizations on advocating for is to focus on the outcomes, and then there’s not one size fits all as to how you get there. Because every organization is unique, and that is a message that seems to be resonating, not surprisingly.
Brijesh Ammanath 00:04:29 Thank you Jon. And I also know that in your book you talk about business agility. I wonder if you could explain a bit about what is business agility and why it is important.
Jon Smart 00:04:38 So, we are lucky enough to be alive in a once-in-a-hundred-year pivot in ways of working, in how we do what we do. And it might even be more than once in a hundred year, it might actually be once in 250 years. So what is business agility? It is improving ways of working in order to improve outcomes. And the background to this is repeating technology-led revolutions. And so back in 1771, we have the first industrial revolution, and that was the very first time that we went from kind of craft working to division of labor and working in a factory. And it is still the case today, 250 years later, that you can trace the DNA of ways of working in a large organization, which is doing knowledge work which is unique and unknowable: You can trace the ways of working all the way back to 1771 and the very first factories that were in Darbyshire, in Northern England. And so, business agility is improving ways of working to deliver better outcomes. And it’s triggered by the latest technologically led revolution, which is the age of digital. And it’s driven by competitive pressure because no longer can companies take a long time to have a feedback loop on the value that they’re producing.
Brijesh Ammanath 00:05:59 Right. And do you think business agility, or the lack of rather, are more of a problem in large enterprises rather than smaller forms?
Jon Smart 00:06:07 No, I don’t actually. So I think that, I think it’s less to do with size and it’s — because what I’m quite interesting, what I’m seeing is for both small and medium companies, it doesn’t take long for small and medium companies to end up with the same level of cautiously use the word ‘dysfunction’, that the same level of bureaucracy and dysfunction as a large company. And it doesn’t take long for people to start to introduce more process, more gated controls, and to slow down the flow of value irrespective of the size. And there are some relatively small companies I see who are not very nimble and don’t have a lot of agility. So yeah, I think it’s kind of a, it’s a human characteristic to keep adding more process and bureaucracy.
Brijesh Ammanath 00:06:57 All right, irrespective of size, business agility or lack of problem which is across the firms in the industry right now.
Jon Smart 00:07:04 Yes. If the organization doesn’t have an intentional priority and focus on time-to-value and time-to-learning and minimizing time to learning, then yes that’s the case. Yes.
Brijesh Ammanath 00:07:16 You mentioned the four metrics: better for quality value, which is unique, cares sooner for time to market, safer for governance and compliance, and happier for morale. We’ll take into each of these measures, but I just wanted to understand, when you look at it holistically, is any one particular measure more important depending on which stage the company is at or the project or the program is at?
Jon Smart 00:07:42 I would say no, definitely not. What I would say is that the five measures of better value, sooner, safer, happier are equally important because they are balancing outcomes. So what we’ve seen is that organizations that reduce time-to-value but do it badly, for example, working people harder rather than improving the system of work and removing impediments. What happens not surprisingly is quality goes down and happiness goes down. So they are balancing measures. So if you are reducing your time to value, you are delivering value sooner. You should see quality get better and you should see happiness get better. And if you don’t, you know that you’re not going about it the right way. So, I would say that they are equally important.
Brijesh Ammanath 00:08:27 Right. With that let’s deep dive into some of the patterns and anti-patterns that you have covered in the book. And you also touched on the first anti-pattern that you mentioned in your book, which was doing an Agile transformation. Why is doing an Agile or a Lean or a DevOps transformation an anti-pattern? Can you expand on this and its related pattern, which is the focusing on outcomes?
Jon Smart 00:08:48 Yeah, so like as I said, Agile is not the goal. Lean is not the goal. DevOps is not the goal. It’s a means to an end, it isn’t the end. And so, often what happens when an organization runs an Agile transformation, all of the focus is on the wrong thing. The focus is on are we doing Agile? How many Agile teams do we have? How many people have been through Agile training? How many product owners do we have? How many teams are doing standups? Yeah, who’s doing sprints? It does not necessarily lead to better outcomes. For example, Nokia mobile Symbian operating system, which no longer exists because they went bust, according to the chairman of Nokia, the thing that killed Symbian was a lack of psychological safety. So bad news was being buried, bad news was not bubbling up. And the Symbian team were scoring, you know, 99% on their ‘how Agile are we’ test, on their Scrum test.
Jon Smart 00:09:42 So Scrum didn’t save Symbian and that’s because Scrum is not the goal. Agile’s not the goal, it’s the outcomes of quality, value, time to value, safety and happiness. So that’s the anti-pattern of Agile transformation. There is a related anti-pattern, which is the word transformation. So a couple of anti-pattern here. One is doing a capital-T transformation, a big bang. A big bang Transformation is an anti-pattern because it takes time for people to unlearn and relearn. And so if an organization does a big bang where you leave on Friday, you are a project manager, you start on Monday, you are a product owner and this is across the entire organization with tens of thousands of people, there is no way that people can magically transform over the weekend. So you end up with new labels on the same old behavior. Humans have a limited velocity to unlearn and relearn.
Jon Smart 00:10:29 So, if you want to go faster, we need to encourage the speed of unlearning. To do that, we need to have more psychological safety. So in order to go faster, the best thing to do is to increase the psychological safety. So that’s the anti-pattern around the word transformation. So the pattern is, instead, focus on the outcomes I recommend better value, sooner safer, happier quality, value, time to value safety and happiness, and think big, start small, learn fast. So don’t do a capital T transformation, do a lowercase t continuously transforming. It’s not a project, it doesn’t have a start date and an end date. It’s about continuous improvement aligned to the outcomes you are never done. Because human systems entropy, human systems go backwards. So it’s about continuously improving with a lowercase t with empowerment and autonomy.
Brijesh Ammanath 00:11:16 Excellent. You do touch on quite a few points and topics that I plan to cover as we go through the session. And I’ll pick on a few right now. So you stress a lot on outcomes. How are outcomes different from outputs?
Jon Smart 00:11:29 So, output works in a factory-type scenario. In the age of oil and mass production, the focus is on output and the definition of productivity is the number of units of output per units of input. So an output is a thing, it’s a deliverable, it’s a widget, it is maybe a piece of software, it’s a system. And if we focus on the output, so for example, have you delivered system X? Have we delivered feature Y? Those are all outputs, those are not outcomes. And so the common anti-pattern here with organizations is a relentless focus on the output but with hardly any focus at all on the outcome. So the reason for the output is to achieve a certain outcome. So the outcome might be increased market share, increased revenue, support more first time buyers onto the property ladder. It might be increased market share in Latin America, it might be help people to buy affordable furniture for their apartment.
Jon Smart 00:12:26 That’s the outcome. So then it might be happier customers might be another outcome. The output is how you might achieve the outcome. So this is a big mindset shift. This is a big mindset shift from output to outcomes. And this includes experimentation, an experimentation mindset. Because change is unique, change is unknowable, there are unknown unknowns, we don’t know what we don’t know, we’ve never done it before. And the only way to learn is by doing. So, we have to run experiments, and we have to minimize time-to-learning and feedback so that we can pivot, so that we can have the cheapest cost of failure is what we’re looking for. So, this is a big change in mindset from — it’s not about milestones in a project plan; that is not the definition of success. The definition of success is the key results in an OKR objectives and key results. Have we actually added a value and are we adding thin slices of value?
Brijesh Ammanath 00:13:23 Right. Moving on, I want to touch on psychological safety because in your book you do mention that this is number one factor in building high performing teams. Let’s start with the basics. What is psychological safety, and why is it so important?
Jon Smart 00:13:37 Psychological safety is the ability to feel safe to ask questions, to challenge authority, to have your voice heard, to express your thoughts without fear of repercussion, without fear of being shot down or belittled in any way. It’s the ability to have open, vulnerable conversations with respect. And it’s also about not having a blame culture. So, if something goes wrong, it’s not because somebody did something wrong, it’s because there was something in the system of work that enabled this thing to happen. So, for an example of this, at British Airways, a cleaner ended up, you know, shutting down a data center, hitting a power switch, which switched off a whole bunch of servers. And that meant that there was a global outage for British airways of their IT systems. And you know the, the CEO of IAG, the parent company blamed the cleaner, blamed the person who flipped the power switch.
Jon Smart 00:14:39 But no, the real thing at fault there is that it was possible to flick a switch to power down the data center. So that’s the key thing about psychological safety, it’s a generative culture where people can challenge authority. Just one other example is where the first captain, the first officer, imagine you’re flying a plane, you’ve got the captain and you’ve got the first officer. So psychological safety is the ability for the first officer to challenge the captain and for the captain to respond productively and positively to the challenge. And there is at least one air disaster, if not more, where there was a lack of psychological safety between the captain and the first officer. So, the first officer saw a problem but didn’t say anything because they were fearful for being shouted at and then that led to an accident.
Brijesh Ammanath 00:15:26 Right. So closely related to being able to speak up and express your opinions.
Jon Smart 00:15:31 Correct, yes.
Brijesh Ammanath 00:15:33 How can leaders create a psychologically safe workplace?
Jon Smart 00:15:37 And my go-to reference on this is Amy Edmondson and her book called, the Fearless Organization, and I’m going to quote Amy Edmondson on this in terms of how to do this. So, step number one is set the stage. Step number two is invite participation. Step number three is respond positively. So, step number one set the stage: psychological safety is important to us. It’s a behavioral trait which I as a leader, you know, I value this behavioral trait very much. I’m very keen to nurture a culture of psychological safety. What that means is it’s not about blaming people, there’s a blame-free culture. It’s about the system of work. And if you have an opinion, if you have a thought, you can respectfully challenge people with emotional intelligence and so on. So that’s setting the stage indicating that this behavior is desired.
Jon Smart 00:16:36 Number two, invite participation. So then if something does go wrong, there’s often learned helplessness with people, and so, just by saying, ‘hey everyone behaves in a psychologically safe manner’ it’s not going to happen — especially if there’s been a culture of fear in the past. It takes, I’ve seen this happen where leaders have said we want there to be a psychologically safe environment, but the people have had so much fear in the past that it takes, you know, two or three years before people start actually feeling safe. So, you’ve got to really encourage people. So that’s invite participation: let’s celebrate intelligent failure, have a town hall, like actually celebrate learning through failure. That’s number two. Number three is responded positively, respond productively. So, when something does go wrong, role model the behaviors. You know, make it all about the system of work, make it all about what could we do to prevent this from happening? And it’s not about the individual. And also, I think, when having kind of team sessions, psychological safety is allowing people to express their thoughts and just acknowledging that everyone’s perspective is right, you know? and not putting people down or not saying you are wrong, but just honoring other people’s perspectives.
Brijesh Ammanath 00:17:47 Thanks Jon. I think psychological safety, you have explained it very well, and our listeners will now know why it’s important and what it is. In your book about leadership, you also talk about transformational leadership. What are the attributes of transformational leadership?
Jon Smart 00:18:02 So, the attributes of transformational leadership, there are four components. The first one is to role model, to walk the talk. The origins of the word ‘lead’ comes from ‘to guide on a journey’. That’s where the word comes from: to guide on a journey; it doesn’t mean, hey you go and do that thing and I’m going to stay here, I’m not going to change. So, role model, walk the talk. Number two is articulate a clear vision. So, this is painting the picture very clearly of what the goal is, what the vision is, what the purpose is. And it should be something that really does have purpose, so that people feel intrinsically motivated. So, for example, making the world of work more humane. That’s a great vision with lots of purpose. The third attribute of transformational leadership is intellectual stimulation. And this is about challenging the status quo, questioning assumptions, experimentation, and requires empowerment, requires autonomy with a very clear goal. And then the fourth one is being a coach. So, this is the leader as a coach, coaching people, developing people, recognizing strengths in people, and helping people to grow.
Brijesh Ammanath 00:19:17 Thanks Jon. You’ve touched on system entropy, and I think that’s something you also go into depth about while you describe the anti-pattern ‘going faster leads to going slower.’ Can you expand first on what is system entropy? How is it related to technical excellence? And then maybe expand on the anti-pattern itself?
Jon Smart 00:19:38 Sure. So, entropy, so human systems entropy, technical systems entropy, and what that means is they kind of go backwards over time, kind of get worse. In the case of technology, there’s more technical debt, there’s more treacle, it takes longer to get stuff done. In the case of human systems, there’s more bureaucracy, there’s more process, there’s more approvals, there’s more committees. And we people, we humans, you know, we like to keep on adding processes, rather than taking things away. So, given that human systems entropy, given that technical systems entropy over time, i.e., go slower, get more sticky, more treacle-like, it is necessary to continuously improve — continuously improve in terms of culture, in terms of process, and in terms of technology. So, technical excellence is very important here because, and this is the problem, if the focus is just on Agile and just on Scrum, there’s nothing there about technical excellence, unlike extreme programming where there is a focus on technical excellence. So, it’s very, very important to have a focus on technical excellence continuously, to continuously refactor, to continuously improve, and to dedicate some bandwidth to that continuous improvement. Improving daily work is as important as daily work. And, not doing that, you end up with a go slow to go faster, or you will end up going slower.
Brijesh Ammanath 00:21:07 Right. So, the recommendation of the pattern that you should adopt is go slower to go faster.
Jon Smart 00:21:12 Correct. And it’s a bit tongue in cheek and what that means is make sure that it’s important to put time aside all of the time for continuous improvement. In the case of technology, for refactoring and continuously improving not only the technology but also your ways of working as well.
Brijesh Ammanath 00:21:30 Right. In this context you also talk about evergreening. What is evergreening, and how can teams be intentional in adopting it?
Jon Smart 00:21:39 Yes, evergreening means always staying up-to-date with the latest versions of libraries, the latest supported versions of software, and never allowing yourself to get so far behind that it’s almost impossible to catch up again. And again, a bit like refactoring, it requires intention, it requires being deliberate, it requires bandwidth, it requires time, and it requires money to always stay up to date with the latest version of software.
Brijesh Ammanath 00:22:05 Thanks. Any examples come to mind where firms have not done it and what was the consequence?
Jon Smart 00:22:11 Yep. So, an anonymous example, one large organization where historically there had not been a focus on evergreening the technology landscape, there was a lot of software which was completely unsupported. And I mean, like, a lot of software — in some cases kind of mission-critical parts of the organization. And in some cases, the software that was being used or the platform or the language had been out of support for you know, 10, 15 years. And not only that but actually was outside of the license, and that was because of a lack of a focus on the topic. And another example is where a third party — I’m sure everyone has seen this in large organizations where you’ll have a big third-party system and that big third party system doesn’t get upgraded over time and it’s so out-of-date that you have no choice, you now can’t upgrade to the latest version.
Jon Smart 00:23:05 And so, one example at one organization I worked at, in order to plug in some in the context of financial services to plug in some pricing modules, it was necessary to use an unsupported out-of-date old version of the C++ compiler because the third-party product was so out-of-date. So, it had a knock-on effect where everything was kept at an old version, and it was impossible to upgrade it, so it forces you into a corner where the only thing you can do is slash and burn and rewrite or roll out a new system, which is also not a good idea. So that’s an example of the implications of not having an evergreen-type of focus. Just one thing to add actually it also holds the business back. So, the ability to add business value, it takes longer, it’s harder, and there was a whole load of stuff that can’t be done because of a lack of being evergreen.
Brijesh Ammanath 00:23:58 Right. I completely agree with you and I’ve seen quite a few examples in my career as well, whether that’s been not C++ but VB6 or Cobol and so on where it’s just been a struggle to upgrade and keep it up to date. You’ve touched on value and value is usually answering the question, do our solution meet the needs of our customers and the business? But this is a lagging indicator. Are there any leading indicators that help measure value?
Jon Smart 00:24:22 That’s a good question. So, what I find works well is using OKRs to measure value, an OKR — objective and key result, or outcome and key result is what I prefer to call them. And within the key results, the key results are your measures of value. And what I recommend is some of your key results are leading key results, they are indicators that might lead to later value. And some of your key results are lagging key results, which are value. So, for example, your lagging key results might be customer net promoter score has gone up by 10 points. And another one might be we’ve increased our market share from 55% to 65%. So those are two lagging value measures: Customer happiness and market share. Some of your leading value measures might be: we’ve had more downloads of the app on the app store; that itself is not valuable.
Jon Smart 00:25:20 However, it is a leading indicator that might lead to the lagging value. Another example would be: we’ve gone from 10,000 to 20,000 online applications for a new product using our app from the app store. Again, the number of online applications is itself not valuable, but it’s probably going to lead to an increase in market share. So that’s an example of leading and lagging value measures. And what you’re trying to do there is you’re trying your leading indicators, your leading key results, you are trying to minimize time to learning and minimizing time to value. You’re trying to get a really fast feedback loop, and this is where kind of ‘carpaccio’ comes in: you want really thin slices of value, get it out to market, get it in the hands of a customer, and then let’s see, you know, do the key results start moving.
Brijesh Ammanath 00:26:08 Right. Makes sense. Before we move on to some of the other patterns, I did want to, you know, just wanted to have one final question on tech excellence, which is what are some good metrics to measure technical excellence?
Jon Smart 00:26:20 That’s a good question. I would say off the top of my head, for me it all comes back to like the lagging measures of time-to-value — so, lead time, flow, efficiency, the amount of time the work is being worked on versus the end-to-end lead time, quality (and by quality I mean failure demand, I don’t mean defects), I mean unplanned work, which is failure demand, that’s another measure, quality and safety. So, in terms of better value, sooner, safer, happier, the word safety and safer is, in particular, to do with mandated controls like information security, data privacy, encrypting data, app move, encrypting data at rest, two factor authentication, not making the newspaper headlines because customer data has been hacked and leaked onto the internet. So safer is another important measure and then obviously I think obviously, but this one’s usually missed, is happier and that’s happier colleagues as much as it is happier customers. And that’s something that’s missing from the DORA metrics, you know, or from accelerate, you know, the word happier is not there; that’s the one that’s usually missed. So, I would say ,in summary, I would say time to value, lead time and flow efficiency, quality, safety and happiness, all of which leads to business value.
Brijesh Ammanath 00:27:45 Agreed. I guess the greater the technical debt that you’ve got, the slower you’re going to be and the unhappier developers are going to be because they’re going to spend a lot of time. Yep. Working on stop, which is quite old and legacy.
Jon Smart 00:27:57 And difficult to work on and yeah and has a long lead time. The flow efficiency is low and also quality will be poor as well. In terms of complexity that fits in your head, you know, if it isn’t possible to have a short lead time, it’s going to end up being big change and that’s complexity that doesn’t fit in your head, you’re more likely to have quality problems.
Brijesh Ammanath 00:28:16 Agreed. So, moving on: in your book, you write about building the right thing, and in this context you write about intelligent flow and intelligent control, which is around building the thing right. Let’s start off by understanding what is intelligent flow?
Jon Smart 00:28:29 So intelligent flow — also known as lean portfolio management — there are two components to this. The first component is horizontally having multidisciplinary teams. Long-lived, multidisciplinary teams aligned to the customer and aligned to the flow of value. So, for example, in financial services it might be mortgages, it might be current account. In an investment bank, it might be equity trading. In an energy company it might be low carbon value stream, it might be gas and it might be electric vehicle charging. So that’s the first dimension to intelligent flow is long-lived multidisciplinary teams with long-lived products, both business products and IT products aligned to the customer. So, there are three things you need. You need to have a thing of value, for example, electric vehicle charging, you need to have value consumers, the customers that turn up and charge their electric vehicles.
Jon Smart 00:29:28 And you need to have value producers, the team, both the software engineering teams and the hardware teams and the electrical engineers that create the electric vehicle charging points. So, if you’ve got those three things, something of value, a consumer and a producer, you have a value stream. So that’s one dimension. And then on top of that you have then a vertical dimension and this is where the OKRs come in, the outcomes and key results. So, on top of your nested value streams, you have your OKRs. So now what we have is we have a multidisciplinary team aligned to the customer, they’re long-lived with a long-lived product and they have a very clear goal to achieve, which unites the team across the role-based silos. So, we could have electrical engineers, we could have marketing, we could have sales, we could have software engineering. Everyone has the same goal, and the goal is on the value stream.
Brijesh Ammanath 00:30:19 Got it. So, three attributes, value, consumer and producer and long-lived team. Yep. For a long-lived team, which is multidisciplinary. What’s the career path? You know, how do you retain that team? So, you might have the best of intents and if you’re leading such a team and you manage to create it, how do you ensure that you know there’s a retention and what’s a career path for somebody who’s within that long-lived team?
Jon Smart 00:30:43 Yeah, that’s a great question. So, especially in a large organization, value streams are nested. You have a double click. So, if we take, for example a bank, a bank is a value stream, double click within that you’ve got retail bank, corporate bank, wealth, investment bank, global markets, and so on. Double click on the retail bank, you’ve got mortgages, everyday banking, maybe pensions, I don’t know, tax-free savings. So, likewise in the investment bank you’ve got equity trading, debt trading, research. So, organizations have nested value streams. So therefore, there is room for career progression within the nested value streams. So, an individual might be a product owner at the team level, there is career progression there to become the product owner at the team of teams level the next level up, and then the next level up, and then the next level up. There is also career progression.
Jon Smart 00:31:33 So in terms of long-lived teams — just to be really clear, what is meant by this is it’s not a case of come together, do a project and disband, which is how it used to be — it also means that it doesn’t mean that people are stuck in a team forever. So, there still is mobility, there still is the ability to move around, but it’s just not all of the time, and it’s not based on a project. So, it could also be that there’s an area that’s very small, maybe there’s two teams, and career progression could be to go and work in another value stream, which is much bigger and maybe there’s 20 teams. So, your sphere of influence and your sphere of control has just grown significantly because it’s a bigger area. So, there is a very clear career progression. And just to mention one other thing, the pattern that I find to work well is there are three leadership roles at every level:
Jon Smart 00:32:24 There’s the value-outcome lead, also known as a product owner. There’s the team-outcome lead or the delivery lead, also sometimes known as a scrum master or a scrum of scrums master. And then the third one is the technical lead, the architecture outcome lead or the technical lead. So that is, you know, the IT software engineering plus architecture lead. Now those three roles exist at the team level, and they might just be a hat that people wear. It might not be a full-time role; it could just be a hat. And those three roles exist at the team of team’s level and the team of team of teams and so on and so on and so on. So again, there is career progression there as a value-outcome lead, as a team lead, or a team of teams lead, and as a technical lead.
Brijesh Ammanath 00:33:09 Thank you, that was a very good answer. We’ll move on to another pattern. If you could expand or tell me a bit more about the milestone-driven predicted solutions anti-pattern.
Jon Smart 00:33:21 Yeah, so that anti-pattern is where the definition of success is hitting a milestone, a predetermined milestone in a project plan which was put together at the point of having learned the least. It is traditionally how organizations have measured success, which is a RAG status. Red, amber, green, you know, is your milestone in your plan? Is it red, amber or green? And in particular when there is a, I’m sure we’ve all seen this, where there is a lack of psychological safety, nobody wants to put red on their RAG status on their milestone because you get summoned to the big boss, to the senior leader who if there is a lack of psychological safety, will then give people a hard time around ‘why are you late on your milestone’ rather than, ‘how can I help you to achieve this goal’? So then obviously what happens is bad news is buried senior leaders never hear about anything.
Jon Smart 00:34:08 Everything looks like it’s green until there’s a massive failure with sunk cost fallacy and things fails to be delivered, which is quite often, quite often observed from old ways of working. So that’s absolutely an anti-pattern. And organizations are complex adaptive systems. The butterfly flaps its wings and there’s a tornado a thousand miles away. We don’t know what we don’t know. There are unknown unknowns, we can’t possibly predict the future. So therefore, a milestone, the origins of which come from the Roman Empire, they weigh two tons, they are sunk six feet into the ground, and they are immovable is a very bad analogy for change, for unknowable change where actually we want to be adaptive and we want to have agility.
Brijesh Ammanath 00:34:50 Right, so if I get it, what you’re saying is that milestone-driven predicted solution is an anti-pattern because it drives the wrong behavior and it incentivizes the members to hide information so that because red state has seen as something which is bad.
Jon Smart 00:35:07 There’s that if there is a lack of psychological safety, there is the added complication of burying bad news. But even if there isn’t that lack of psychological safety, it’s still suboptimal to view success as a milestone in a Gantt game chart because typically that milestone, again, because it’s a focus on the output, not a focus on the outcome; it’s a focus on did we build system X by date Y or have we not? And the business case was written 18 months ago, no one has ever looked at the business case since; there’s no causality. The time from cause and effect is so long that you can’t possibly measure value because it could be just a change in the macroeconomic environment. So instead, this is the pivot to focusing on the outcome rather than on the output.
Brijesh Ammanath 00:35:53 Right. Got it.
Jon Smart 00:35:54 Building the wrong thing faster makes it more wrong.
Brijesh Ammanath 00:35:56 You touched on Gantt charts; you have a strong opinion on it. Can you start by explaining to our listeners what a Gantt chart is, its historical use, and why you don’t favor its use?
Jon Smart 00:36:07 So Gantt charts, Henry Gantt worked with Frederick Winslow Taylor in the early 1900s in the context of manual labor in factories. And the line in the Gantt chart originally used to be called the mandates quota. And what it meant was, if you’ve shoveled enough coal into the boiler, you can go home. If you haven’t shoveled enough coal or if you haven’t produced enough steel, then keep on working. And so, it was used with a mindset of “manual laborers are dumb, manual laborers are stupid, manual laborers need to be told what to do and can’t be trusted.” So, that’s the general school of thoughts from Taylorism at the time with time studies rather than time in motion, which came later. And so, that’s their origins. And just one thought, which is to quote Eisenhower planning is indispensable, but plans are useless. So, the act of planning is a very good thing, and with Agile ways of working, you’re actually doing more planning than you are with a waterfall way of working with a traditional sequential, big batch way of working because you’re planning continuously.
Jon Smart 00:37:17 You’re doing everything continuously, so you can do anything badly — so you can use a Gantt chart well. So, I’m not completely opposed to a Gantt chart because a Gantt chart with lines representing activity can be used in the right context, and it can be used to visualize the future; it can be used well, and it can be used badly. So, what I recommend is, first and foremost, fixate on the outcome roadmap, not on the output roadmap. So, and what I find works well is imagine like a double-layer roadmap. So, the top layer of the roadmap is your three-year OKR, your one-year OKR, and then your quarterly OKRs. So, where do we want to be by the end of Q1? Where do we want to be by the end of the full year? Where do we want to be in three years’ time? And that’s all expressed as outcomes, not as solutions.
Jon Smart 00:38:04 Underneath that, when you double click on your quarter to the OKR, you will have some monthly epics or experiments or features, and then you’ll have some weekly iterations and some daily stories. And it’s okay, like below the quarterly OKR, I think it’s okay to visualize, you know, what the roadmap might be for the product, but the important thing is the output roadmap should be pivoting all over the place. It shouldn’t be locked down; there should not be change control. The outcome roadmap above isn’t going to change very much. Yeah, we want to increase market share, we want to increase profit margin, we want to have happy customers, but underneath that there should be an enormous amount of agility to run quick experiments. We’re going to try this in the product roadmap, we’re going to try this, we’re going to try this. If it works, amplify. If it doesn’t work, dampen, pivot. So yeah, so that’s my thought process on kind of planning.
Brijesh Ammanath 00:39:01 So if I understood that right, what you’re saying is that you’ve got your three-year roadmap, one-year roadmap, and then your quarterly roadmap, and underneath the quarterly roadmap, which has got the outcomes, you could use Gantt charts to show how work is progressing to achieve that outcome?
Jon Smart 00:39:21 So yeah, and I wouldn’t get to, personally I don’t think, it’s not about getting too hung up on a Gantt chart — using a Gantt chart or not using a Gantt chart. From a principal perspective, yes, first and foremost, fixate on the outcome roadmap, not the output roadmap. Whether you use a Gantt chart or not, first and foremost, focus on the outcomes. And then when you double click on the outcome underneath the outcomes, you know, you will have an architecture vision, you will have an architecture roadmap, you will have a product vision, you will have a product roadmap. And we need to have that, we need to visualize the future for this product. But the important point here, whether you use a Gantt chart or whether you use an Excel spreadsheet or Google sheets, doesn’t really matter. The most important principle here is the product roadmap, the output roadmap, should be pivoting all over the place.
Jon Smart 00:40:09 It should be changing frequently, and it should be changing frequently based on thin slices of value, minimizing time to learning so that we can pivot, so that we can achieve the outcome. So, if I give you an example, an outcome might be we want to get to the town which is over the river and we’ve got 20 people to get across the river and we want them to be dry and happy. Dear team, you are free to figure out how to cross the river to get to that town. Not telling the team whether to build a bridge or build a boat or for people to swim. In the past, what we would’ve done is we would’ve had a project plan where we would’ve said build a bridge, and told the team exactly what to do with requirements handed down the line. But now team, you are free to go figure.
Jon Smart 00:40:53 So then the team run a cheap experiment. One person tries to swim, yeah, it’s too deep, it’s cold, we’re not going to get 20 people across happy. Someone else quickly builds a quick basic canoe. They canoe across, ah, you know what, the water’s flowing too quickly. There’s rapids, didn’t make it across, someone else builds a zip line. Ah, awesome. The zip line works, everyone’s dry, it’s quick. So, the solution ends up being the zip line. So, I hope that kind of analogy helps bring it to life where the product roadmap should be pivoting all over the place to maximize the outcome.
Brijesh Ammanath 00:41:23 No, it does, it does. Just one thought came over there, which is around incentive model that you will have. So, will the incentive model then be aligned towards after achieving the outcome? Or will that be, and if the outcome is, say after three years, you know your market share goes up by X percent after three years, how do you incentivize the team during this period? What models should it be following?
Jon Smart 00:41:47 Yeah, that’s a great question. So incentives are so important, and I think you can boil down ways of working — how we do what we do, improving ways of working — you can boil it down to one word, which is incentive. And the other side of incentive is threat. And it’s very important to, as per your question, is to align incentives. If incentives are not aligned, there will be problems. So, to answer your question around incentives, this is where OKRs I find work really well when they’re done well. So, the anti-pattern is to have OKRs in a role-based silo. Engineering OKRs, quality OKRs, product OKRs, marketing OKRs, sales OKRs, pattern, anti-pattern. The pattern is to have value-stream-aligned OKRs. So again, this could be mortgages, it could be current account, it could be low-carbon energy, it could be medicine in healthcare. So, what happens here is when you have OKRs which are aligned to the value stream, aligned to the flow of value in your company, the things that you do of value.
Jon Smart 00:42:53 It could be streaming at Disney, it helps unite people across the job roles to a common goal. So now it doesn’t matter whether I’m marketing, sales, engineering, quality, whatever, we’re all united, we’re all rowing in the same direction, and we succeed or fail — and there is no failing, it’s just learning — we succeed and learn as a team together. And I’ve seen it lead to some really good human behavior where people get behind each other and they help each other out. And it’s a truly multidisciplinary team. Not only multidisciplinary in IT, but genuinely business plus technology plus ops, multidisciplinary teams. So OKRs are a great way to align incentives,
Brijesh Ammanath 00:43:37 Right. And I think it’s related to the anti-pattern local optimization where you see only IT getting optimized or only of one team of the value chain getting optimized. Can you tell our listeners a bit more about local optimization and also maybe give the example of the team that reduce the time between pulling work from the backlog to the end of development, but still the benefits were not visible to users. What went wrong over there?
Jon Smart 00:43:59 Yeah, so to quote Ellie Goldratt, author of the Goal, a system of local optimums is not an optimum system. And local optimization means improving in one role-based silo only. And for example, that could just be improving in software engineering, improving in IT. And if it’s no longer the weakest link in the end-to-end chain, there’s no point in continuing to strengthen it. If it’s no longer the weakest link, the weakest link is now moved. The theory of constraints — put all of your resources behind the biggest constraint, the biggest bottleneck in the end-to-end flow: The bottleneck moves somewhere else, the weakest link moves somewhere else. Identify it, repeat, and repeat for infinity. So, the example here is where, you know, you’ve got the end-to-end flow of value, your biggest impediments are typically upstream, typically annual budgeting, the kind of the portfolio management process, the funding process. And the biggest impediment is not software engineering. And yet, you know, still it’s like teams could spend lots of time and effort in reducing the lead time and you could reduce it by 50%. However, it only has a 5% impact on the actual end-to-end lead time of value because the biggest impediment is upstream.
Brijesh Ammanath 00:45:17 Yep, agreed. And what would be the way to solve for it? What’s the corresponding pattern?
Jon Smart 00:45:22 Number one, visualize. Visualize the system of work end-to-end. So, a great way to do this is value-stream mapping. Get all of the experts in the physical room or the virtual room together at the same time, so you’ve got experts who know each little bit of their end-to-end process, and actually map it out — for the first time ever , usually. Visualize it physically or virtually, so we can actually see the end-to-end flow. And then ask people for roughly how much time is work waiting in-between these stages, and roughly how much time are you spending adding value to the work? And then, you know, it’s quite easy to then come up with an approximate measure for flow efficiency — flow efficiency again being the amount of time that work is being worked on versus the end-to-end lead time. For most organizations, flow efficiency is 10% or less, which means that work is sitting in a queue waiting for 90% of the time, which is shocking. That’s incredibly low, and most organizations are unaware of it because they’re not measuring it. So number one, visualize and measure; make it visible, measure the system of work, and then identify your biggest impediment to the flow value. It’s usually quite obvious. And then work out what, you know, you’ve got an impediment, work out how you can alleviate that impediment. Run some experiments, start with the champions, and then repeat for infinity.
Brijesh Ammanath 00:46:41 10% is a shocking number. So what you’re seeing basically is local instead of local optimization, you should be optimizing for the bottlenecks to reduce the flow end-to-end.
Jon Smart 00:46:52 Yep. Correct. Take a look at the flow end-to-end. Yep. From concept to cash.
Brijesh Ammanath 00:46:55 Right. Moving on, let’s touch on ‘build the thing right’, which is about continuous compliance. What would be a multidisciplinary control team?
Jon Smart 00:47:09 So, we call them a safety team. And this is a pattern that works well, which is: in your safety team, you’ve got a multidisciplinary, effectively a specialized secondary team. So, you might have 10 product teams aligned to a value stream. Let’s assume it’s mortgages in a retail bank. And then you’ve got your safety team, and in your safety team you’ve got information security, data privacy, fraud, anti-money laundering, compliance, maybe enterprise architecture, anyone who has some mandatory risk stories that need to be implemented. And those could be external regulation or it could be internal standards, policies and standards. And the pattern that works here is it’s a long-lived team. So, it’s always the same people. The anti-pattern is, you know, you go to InfoSec, you speak to InfoSec, you speak to data privacy, it’s always somebody different, you never speak to the same person, they don’t understand the customers’ context, they’re not specialists in mortgages.
Jon Smart 00:48:08 So that’s an anti-pattern, and that’s the world that I’ve experienced in the past. So, with these long-lived safety teams, you can have some amazing innovation coming from the safety team who actually deeply understand the customer and the customer’s unarticulated needs. And it’s not one-size-fits-all because the safety team once a quarter, there’s a formal kind of conversation with the product teams, this is what we’re planning to build in the next quarter based on our OKR. And then the safety team will decide on kind of the risk appetite on the risk profile. And then it might be a case of we’re going to talk every day, we’re going to join your standup. Or it might be a case of it’s not risky at all, so we don’t need to speak for another quarter. And it’s also not one-size-fits-all when it comes to the risk stories that are going to be implemented by the teams. So, if you’re building something that’s risky, you’re going to have a whole load of risk stories, encrypting data and so on two-factor authentication. If what you’re building is not risky and it’s internal, then don’t worry, you know, you don’t need to do all these things. The anti-pattern, which is how it used to be for most companies, is one-size-fits-all: everyone has to comply to the same 200 set of controls.
Brijesh Ammanath 00:49:15 Do you have any specific examples where things have gone wrong by not focusing on safety?
Jon Smart 00:49:21 So I don’t, because what I have experience of implementing is we built in the safety checks so we could see both left to right and right to left. So left to right is the path to production. Programmatically, we could see if someone had not implemented a mandatory risk story and that was reported in a report; and right to left is going backwards along the software development lifecycle, we could see if somebody had pushed a new binary into production, and if we couldn’t trace it back to the risk stories that also showed a big red light in a report, which was then followed up at a senior level. So actually, what I’ve seen is, yeah, we managed to get to a point where there was both speed and control, not just speed out of control or control with no speed. Just one other thing to mention, Brijesh, is that where I have seen it cause a historically be a problem in the old way of working is, you know, we had a, like an Agile lighthouse initiative and it was meant to be a big fanfare in the spotlight and hey look, great case study of Agile ways of working.
Jon Smart 00:50:28 And it was, like, the day before go live super Agile and information security came up with six months of unplanned work. That was the old way of working. And you know, it’s like we’re going to inspect it at the end and oh here’s a bunch of new requirements. So, that was funny because this was meant to be a showcase for Agile ways of working and you know what we learned? It absolutely was not Agile at the end, and we learned from it.
Brijesh Ammanath 00:50:52 Right. And this was primarily because the safety team was not closely aligned?
Jon Smart 00:50:57 There wasn’t a safety team. Okay. Yeah, in that particular example. This was before we even created the concept of a safety team. So that was an example of the old ways of working where, you know, we’ll inspect it at the end and oh by the way, here’s a bunch of new requirements. And it was probably because it was someone different every time you’d speak to InfoSec or data privacy.
Brijesh Ammanath 00:51:19 I want to touch on the measure Happier. How do you measure team morale and satisfaction? Any suggestions on that?
Jon Smart 00:51:25 Yeah, so a couple of ways. The first way is usually there is an existing HR colleague-engagement survey which is running. And so, they usually have a colleague-engagement score. So, it’s usually pretty easy because it already exists. And start with that. The other thing that I recommend doing, that we normally do, is we also have our own Colleague Ways of Working survey. And typically, we’ll alternate the external third-party colleague survey — usually being run from HR — with the ways of Working Colleague survey and the Ways of Working Colleague survey is, the questions are very specifically worded to do with ways of working. And what I’ve found to work well is we ask the same questions every single time. It goes out every six months, so it kind of alternates with the HR one, which is every six months. So effectively we, every quarter, we have a feedback loop and it works really well to ask the same questions.
Jon Smart 00:52:18 And one of the questions is a net promoter score type question. So, in terms of how we me measure colleague engagement, not only is there the proprietary third-party engagement calculation, there is also our own net promoter score type question. And every single time we see the Kubler Ross curve, we see the peak of excitement, we see the trough of disillusionment, all this is hard and then we see people climbing out of the hole. So, it’s always up, down, up is what we see on the net promoter score. And we also, what also works really well is to have free text fields in that survey. And what we do is we use the colleague feedback to then drive the strategy for the next quarter. So yeah, every time I’ve done this, we’ve put a lot of effort into listening to what colleagues are saying, which then influences the approach.
Brijesh Ammanath 00:53:02 Right. Thanks Jon. In the last section, I’d like to close off the show talking about what’s in the future. We have seen software development methodologies evolve from waterfall to an iterative model using Agile Lean principles and other tools. As software changes with introduction of AI, machine learning, and no code, how do you see software development methodologies evolving? So, what would be the new, new ways of working?
Jon Smart 00:53:26 I think it’s even more kind of biz DevOps, if you like. I think there’s still a big, what I observe is there’s still a big gap between, in quotes, “the business” and technology. There’s a lot of room for improvement in terms of properly multidisciplinary teams, which are business and IT together. You know, we can still have reporting lines into technology, we can still have reporting lines into non-technology. The difference is that the work is not flowing through the reporting line. The difference is the reporting line is there for personal development and career growth and care for the individual, and work is flowing through the value stream. So, I think to answer your question, Brijesh, I think it is increasingly kind of biz DevOps, which for me is a bit back to the future. For me, it’s kind of in my personal experience, it’s how we used to work in the early 1990s. Yeah, I think that’s it. It’s like, you know, this breaking down the barriers even for some Silicon Valley companies, even with the notion of product and engineering, there still ends up being a, like a business silo, a product silo, and then an engineering silo; and product are just doing what business analysts used to do in the past, which is talking to the business, writing requirements, and handing them to engineering, which is not great. So, I think more outcome focused, more value stream alignment, biz DevOps.
Brijesh Ammanath 00:54:43 Excellent. We covered a lot of grounds here, but if there was one thing you would want our listeners to remember from this show, what would it be? And I already have a very good inkling about what you want to say, but I want to hear it from you.
Jon Smart 00:54:54 Focus on the outcomes, that’s it. First and foremost, it’s not about Agile, it’s not about Lean, it’s not about DevOps. Those are tools in the toolbox, first and foremost. Number one, understand what outcomes you are going after. For example, better value, sooner, safer, happier. Feel free to use those words and then measure them and then continuously have fun, continuously improve in line with those outcomes.
Brijesh Ammanath 00:55:16 Great. Was there anything we missed that you would like to mention?
Jon Smart 00:55:20 Only maybe just to reinforce the importance of incentive and the importance of leadership. Leadership behavior will make it or break it. It is: grassroots will hit a grass ceiling, there will be limited success trying to do this bottom-up only. It has to be, in my opinion, this has to be top-down and bottom-up and sideways and middle-out. So maybe just to mention that there has to be an incentive for this to be successful across an organization, improve this being, improving ways of working, improving how you do what you do. There has to be an incentive from the top table to improve. Because if there isn’t an incentive from the top table to improve, people won’t improve.
Brijesh Ammanath 00:55:59 Right? People can follow you on Twitter, but how else can people get in touch?
Jon Smart 00:56:04 LinkedIn. Yep. Twitter, LinkedIn, and also our website soonersaferhappier.com.
Brijesh Ammanath 00:56:11 Jon, thank you for coming on the show. It’s been a real pleasure. This is Brijesh Ammanath for Software Engineering Radio. Thank you for listening.
[End of Audio]
SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)
