BT

InfoQ Homepage Podcasts Allan Kelly on Continuous Digital, #NoProjects, Minimally Viable Teams and OKRs

Allan Kelly on Continuous Digital, #NoProjects, Minimally Viable Teams and OKRs

Bookmarks

In this podcast recorded at the Agile on the Beach (New Zealand) conference, Shane Hastie, Lead Editor for Culture & Methods, spoke to Allan Kelly about his book, Continuous Digital, #NoProjects, Minimally Viable Teams and OKRs.

Key Takeaways

  • The impact of digital transformation on the workplace and larger environment is significant
  • Digital is about encoding activities and work in software – which is fundamentally changing how business happens
  • Continuous digital comes out of #NoProjects thinking as an alternative to the project based approach
  • One of the biggest challenges in the continuous world is knowing when to stop
  • A minimally viable team has all the skills they need to explore the potential of the technology as well as the market opportunity
  • The real power of the OKR's is the shared goals and the shared vision, and the fact that you will periodically sit your team down and say, what should our shared goals, our objectives, be for the next three months

 

Transcript

  • 00:17 Shane Hastie: Hello folks. Before we get into today's podcast, I wanted to share with you the details of our upcoming QCon Plus virtual event taking place this May 17 to 28. QCon Plus, focuses on emerging software trends and practices from the world's most innovative software professionals. All 16 tracks are curated by domain experts to help you focus on the topics that matter right now in software development. Tracks include leading full cycle engineering teams, modern data pipeline  and continuous delivery, workflows, and platforms. You'll learn new ideas insights from over 80 software practitioners at innovator and early adopter companies. Spaced over two weeks at a few hours per day, experience technical talks, real-time interactive sessions, asynchronous learning, and optional workshops to help you validate your software roadmap. If you're a senior software engineer, architect, or team lead and want to take your technical learning and personal development to a whole new level this year, join us at QCon Plus this May 17 to 28. Visit qcon.plus for more information.
  • 01:33 Allan Kelly: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. I am in beautiful Tauranga, New Zealand, for the Agile on the Beach, New Zealand event. And I'm privileged to sit down with Allan Kelly. Allan, thanks so much for taking the time to join us today.
  • 01:48 Allan Kelly: Oh no, my pleasure, Shane. Thanks for having me.
  • 01:50 Shane Hastie: You and I have met for the first time today, but we have been corresponding for years-
  • 01:56 Allan Kelly: Yes.
  • 01:56 Shane Hastie: And it is years, but I suspect a fair number of our audience don't actually know who you are. So would you mind giving me the quick background?
  • 02:03 Allan Kelly: Oh, the quick background. Well, I always start and perhaps this is me trying to establish my credibility with software developers, by saying, once upon a time I was a C++ programmer and I was down in the trenches doing all that. Nobody's paid me to code for about 10 years, so maybe I've lost some street cred.
  • 02:20 Allan Kelly: These days, I help teams, I help organizations adopt, deepen, this thing we call Agile and I'm less and less certain I know what agile is and it's all tied up in this thing we call digital. I don't know if there's a difference. People call me an agile coach and I hate that expression, but I don't know what the better one is.
  • 02:40 Shane Hastie: Let's explore that digital thing. What does digital mean to us today? And you've actually got a book, Continuous Digital.
  • 02:47 Allan Kelly: Yes. Even saying the word, I know a lot of software are going pah, what's this digital, this digital is management talk and it was a slow realization with me that, and for me, digital, is nothing new. And for you, Shane, it's nothing, amongst your listeners. It's nothing new because.
  • 03:03 Shane Hastie: We've been doing this for years.
  • 03:04 Allan Kelly: Yes. Those steam computers they never caught on.
  • 03:06 Allan Kelly: We've always had these digital computers. And so digital is superfluous, but I realized that when somebody not with that background, call them a business person, if you like. Somebody from a different domain, starts using the word digital. What they are saying is their world, now looks like our world. The world we have always been in, the world that is entirely digital to us. We don't even think about it,  they're now are affected by it. And if you look at the way, trends are going globally and particularly in we'll talk about business because that's where we earn the money to pay the mortgage. It's all about this thing, they call digital.  For us. I think we could substitute the word softwarization or software every time they think digitalization, because it's effectively about taking businesses and processes and government and everything else and encoding it in software. And it executes on these machines that are digital. And it's that kind of realization that made me think, hang on this digital word does mean something, it may not mean anything to me, but to the other people are using its important.
  • 04:10 Shane Hastie: So yeah, we hear organizations transforming themselves to becoming digital. Now I want to be cynical and say, is it just putting a software veneer on a bricks and mortar factory?
  • 04:25 Allan Kelly: I'm sure in some cases it is. I'm sure there's plenty of companies out there who are just trying to get a bit of a Kool-Aid ,just trying to look a bit more trendy, a bit more with it. For many businesses, though, it's a life or death issue because software is allowing completely new ways of doing things. We're sitting here in New Zealand. I know you Shane, you work remotely and I've got other friends, friends I've worked with in London and they now work remotely in New Zealand and because of software and the power of software. And now, I'm here in New Zealand. I haven't got any New Zealand dollars, I'm tapping my way around with a Revolut Card and companies like Monzo and Revolut and Starling.
  • 05:09 Allan Kelly: They are changing the banking sector because they're bringing in this new softwareized banking. And while all the banks have got to try and do this, we're just picking on banks because they're a great example, but it applies elsewhere. All the existing banks have to try and play in this space, they have to try and do this stuff. But the legacy banks are really playing catching up with the new starters, the disruptors, to use an expression and they have to play this and they haven't got a choice or there'll be out of business. So, for every business, yes, digital for some is just a charade, for some it's a life or death issue and most people are somewhere in the middle.
  • 05:47 Shane Hastie: The other side of that, the other part of the name of your book, continuous, why continuous.
  • 05:54 Allan Kelly: Partly it’s jumping on the bandwagon, continuous delivery.  To be serious, we've talked about continuous improvement for years and the Kanban folks talk about continuous flow and we have continuous delivery, and you know the commonality? Continuous, and continuous digital came out of the #noprojects, critique, which myself and you, Shane and Evan, and a few other people,  we've been criticizing the project model of managing work. And one of the problems with the noproject movement is, its very good at criticizing things. And we haven't been too good at saying, what is the alternative? And talking it through with people like Evan (Evan Laybourn for people who don’t know him).
  • 06:35 Allan Kelly: Again we kept coming back to this word continuous because the definition of projects, it has a start and has an end and the world we live in where you're continually doing this stuff and you don't want your business to end. You don't want your job to come to an end. You don't want your supermarket to run our food. It's continuous. And now that digital is embedded in everything. It doesn't make sense to start, stop, start, stop. It's ongoing. So there's a number of things that come together and say, look, this digital, this software world we work in, it's always advancing. We need to be continuously working at this and continuously improving and continuously delivering and all the rest of it. It's not, stop-start start anymore.
  • 07:14 Shane Hastie: So what is the implication of that then on teams and teamwork?
  • 07:19 Allan Kelly: In one way, it's really simple. You have a team and a team have a product or a business, and they're just going to keep on doing it again. They’re just going to keep on iterating, another version of software, another upgrade to the business, a new capability for the business, a new bit. And it's continually rolling, which is great when you're on a roll, but you have what I sometimes jokingly call the halting problem or perhaps the new halting problem.
  • 07:44 Allan Kelly: How do you know when to stop? And perhaps more importantly, how do you know when to start? How do you even start? In the old days, we'd say, we've got an idea. We scratch our heads. Somebody does some requirements, somebody does some designs, somebody does some estimation, we package it all together and make it look nice and then we get some funding we call it a project. But now, particularly the way technology's gone, the whole planning phase has changed. It's changed economically. It's not just that we in agile supposedly don't like planning, it's that planning is now really, really expensive.  In 1970, when the waterfall model comes on, planning wasn't that expensive because in 1970 CPU cycles were expensive. People were cheap.
  • 08:31 Shane Hastie: Yeah. It was the cost of using that piece of technology, which today sits on our desk and is effectively free.
  • 08:38 Allan Kelly: Right? Yeah. I have a slide. Some people see me put up pictures of IBM mainframes in 1970 and their vital statistics, 10 MIPS. It surprised me when I looked it up, 256MB of Ram, which is quite surprising. And you compare that with a Raspberry PI 5,000 MIPS, a gig of Ram. And the cost: a 1970s IBM mainframe was quarter of a million a month to rent, quarter a million US dollars, that’s  about 1.75 million us dollars today, to rent, you can buy a Raspberry PI outright for $30. Today, planning humans with paper at desks is really expensive and economically it makes more economic sense to say, just try something and see what happens. The problem is that we need to know when to stop. We need to be able to say, this thing we have started doing, does it make sense to continue doing it?
  • 09:34 Allan Kelly: In the old world, we used to look at the project plan. We used to look at the costings. We used to scratch our heads and we say, yes, we'll do it. Now where we need to run dual track agile, parallel requirements and building. We need, to build in some processes that say, every so often, we have to stop and say, does this make sense? So, we need to think about changing our governance model, changing our portfolio model. As somebody described it the other day we need to unlearn the project funding model. And we need to get comfortable with venture capital style, giving small teams a little bit of money, letting them run with it, let them to explore the technology, explore the requirements, explore the market. And periodically, they come back in and say, we spent all the money. Can we have some more, please? This is why we think you should give us some more.
  • 10:24 Shane Hastie: An interesting thing that, jumps out at me there, explore the market, explore the technology. This has an implication on who’s on that team. It's not just the technologists.
  • 10:35 Allan Kelly: Yes. Yeah. So I like to talk about minimally viable teams and partly that’s because we all love minimal viable products.
  • 10:42 Shane Hastie: One of the most misused terms in the industry.
  • 10:45 Allan Kelly: I know, I agree with you Shane, but let's not go there today, that’s another podcast. So, I believe we get a minimum viable team. We deliberately constrain the team, so that they don't go off on any flights of fancy, they're very focused, and a minimal viable team needs to have both the technology skills to explore what the technology can do and also the skills, whether you call them business skills or research skills, analytical skills, products, commercial skills, I don't care what you call them. Because you need to get people on that team, and its easy to say, look, one techie, one business person, but maybe it's something slightly different. Those people are then tasked with a mission. We've got a hunch, we've got an idea.
  • 11:24 Allan Kelly: I think a minimum viable team in my book, it's probably two or three people. If you've got six or seven, I'm questioning, if it's minimally viable and those people need to go and explore what the technology can do, what the market wants, what people will pay for. That's the important bit,  we can all produce technology people won't pay for. And what the need is, and it's a bit like the iPod problem or the iPhone problem. iPad, anything with an i front of it, - did you know you needed that until you had it in your hand?
  • 11:55 Shane Hastie: No, but once I've got it, you will tear it from my lifeless body.
  • 12:00 Allan Kelly: So sometimes it's about, we do need to be technologically led and that is counter to a lot of what we've been taught. And I completely agree with all the business analysts and product managers who are screaming, as I say that, we need to understand our customer's needs and their problems and all the rest of it. But we need to do these things in parallel. So, we bring just enough skills together in a minimally viable team. We give them a mission. We give them enough funding to experiment, to explore for a bit. And after three months, six months, whatever you're prepared to give them, they come in and they have to justify their existence. And they have to say, we think you should give us some more money or we think we should grow this team. And then you can organically grow it.
  • 12:45 Allan Kelly: And I can also hear some people saying, well, hang on, isn't that also about the product owner's job to say, this is what we're going to do. I completely agree. What I'm going to add to that is that, who would kill their own team, who would honestly, faced with yet another failure in the market, turn around to their own teammates and say, folks, I think it's time we gave up and we pivoted completely, we broke up this team. There does need to be some higher level if you like, not necessarily managerial, but some higher authority, some higher supervision. Somebody who you have to explain yourself to, And somebody who sometimes says it seems, sounds like great ideas. But after a year you haven't made anything work. We need to deploy these resources somewhere else or we need to try something very different; because I don't think we'd ever bring that on ourselves.
  • 13:38 Shane Hastie: So those growth points, how does that team then expand? We've gone beyond the minimally viable team. Now we actually want to turn this into a product that is going to be valuable in the market place.
  • 13:51 Allan Kelly: I think this is the good old Kanban principle of pull. What does the team need? The team needs to pull the resources it needs. If the team realizes it needs an excellent interface, it needs to start pulling in UXD people. The team needs to say, Oh, we need some more Java skills. We need some more testing skills. And the team should be controlling it. In the old world, in the plan driven world, somebody writes a plan. Somebody sets this out and that's all entirely rational. And that makes perfect sense. The problem is, it's disempowering, because whoever creates the plan is in control and plans are a learning exercise. I completely agree. And yeah, the old quote planning is essential.
  • 14:32 Allan Kelly: We need to do that learning, but when we try and execute on that plan, the plan becomes a control mechanism. And you should see the parallels here with budgets and the beyond budgeting people and all of that because budgets are control mechanism as well and plans and budgets all fit together. But if we really want to let the teams be masters of their own destiny, if we really want to put authority in the teams, then the teams need to have a say about what other skills, what other people, what else the team need. And if the team feels, if they need a tester more than the Java programmer, they should get what the team need. Yes, they should have to justify himself.
  • 15:11 Shane Hastie: And where do we fit in things like marketing and maybe finance and HR and those sorts of parts of the organization as well.
  • 15:19 Allan Kelly: I guess in my mind, these teams are all self-contained business units and they contain just enough of all these things. And there is actually a model for this. It came out of Japan, but it's not the company you think it's going to be it's Kyocera and most people know them as a printer company, they started life as a ceramics company, their founder, former CEO, whose name I'm not going to try and pronounce.
  • 15:44 Allan Kelly: He wrote a book called, 'Amoeba Management.' And for those of you who know about Hewlett Packard, it’s similar to the old HP model that you organically form a business unit and you let the business unit grow. And at some point you split it and those business units, the secrets in the name amoebas, they're self-contained. Now I'm sure at some points, most HR functions need to start joining up and linking up and the sales need to coordinate and all the rest of it. I think that's perhaps one of the challenges we have in the future, because the point we are in time, with the way technology is changing the world and radical uncertainty. And we're speaking as Coronavirus is ravaging the world. I'm not sure if I can get back to the UK.
  • 16:22 Shane Hastie: We have a spare room.
  • 16:24 Allan Kelly: Thank you Shane. Things are changing. I don't think we know what the future structure should be. We know that cross functional teams, co-location, those kind of, they work and we need to put people together and we need to experiment in the moment. And I don't think we have enough knowledge to know where the cuts are for, most of the 20th century, there was HR over here and accounting over here and IT over… and we know that model no longer works. Whether in 50 years time, we have just a whole bunch of self-contained amoebas. I'd love that. But maybe in 50 years time, we've found another model that works. One thing I was talking to David Morris about on the drive over from Auckland yesterday is, we both read a bit about the Bauhaus,  it’s a great German design and art movement or the inter-war years.
  • 17:12 Allan Kelly: And one of the things they did at Bauhaus, which was radical in the 1920s was they mixed up the arts. They didn't have courses for textile and courses for painters and courses for sculptures. Everybody got the same foundation course in art and design. And the masters would move between subjects. In the 1920s that was radical. Today in art and design that’s established. We still get sculptures and we still get painters. And we still got all the rest of it. And it seems to me in the technology world at the moment, we need to throw them together, we need to mix things up and we need to find models that work. And touch on something we were saying earlier. It worries me as we expand agile outside of the traditional IT space.
  • 17:54 Allan Kelly: And when we were talking about retail store early on today, we don't have the models. We don't know what works. We know a lot about agile in software development. We're getting a fair bit of knowledge about agile marketing. We've got examples of agile elsewhere. We've got lean manufacturing, lean in supply chains, but there is massive areas of the economy where we don't really know what lean and agile look like. And until we've got more experience, we cannot take a cookie cutter this. We need to experiment and find new solutions.
  • 18:24 Shane Hastie: A lot of learning still to do. One of the things that is always challenging is how do we measure this? And I know you've been doing some work on OKRs, which is it just another buzz word?
  • 18:39 Allan Kelly: Oh God. Yeah. I think for a long time, I thought so. So last year I was engaged with a client and out of the blue, the big consultancy that we were working with decreed they should start using OKR. And I will admit my heart sank. And I thought, Oh God. And I speak as the man who I would claim familiarized the software world with Goodhearts' law, which is a law that says any observed statistical regularity, if used as a target will change its behaviour, which the best example of is story points. If your teams target story points, you will get increased story points. Everything else gest disregarded. So I look at, OKR's, and I think, Oh my God, no you're going to target things and you're going to say what you're going to do, and you're going to measure people against this.
  • 19:27 Allan Kelly: And I thought, okay, right. I'm going to put my instinctive dislike to one side. I'm going to run with this. It's going to be an experiment. It's a bit of a challenge for me. I'm outside my comfort zone, but I'm going to go with this. And what I discovered of the process of a year is, I quite like OKR's and the reason I liked them, isn't usual reason. The reason you get a lot of talk is you get people talking about aspirations and the idea OKR's are stretch goals. And you only have to meet 70% and teams will do this and people will feel empowered and all the rest of it. And I'm sure that's great. I'm sure it works at Google and some other places because that's part of their culture anyway. But I don't see the aspirational thing is a real power of OKR's.
  • 20:10 Allan Kelly: What I see of the real power of the OKR's, is this the shared goals and the shared vision, and the fact that you will periodically sit your team down and say, what should our shared goals, our objectives, be for the next three months. And you will do a little bit of planning around them. You do some key results, and you will involve the whole team. So, one worry with OKR's is that things are normally done quarterly, you'll end up with instead of having six sprints you'll end up with one supersprint. I don't see that, I think you keep the sprints. You still do all your Kanban, but you've got a medium term plan. You've got three months plan. You've got a three-months not even a plan, an idea, a target for three months and three months isn't so big a period that if you mess up, it's the end of the world, but it's big enough to allow you to chase after some meaty goals.
  • 21:03 Allan Kelly: And sometimes when teams are doing sprint, sprint, sprint, they shy away from the meatier goals because they're not sure what's coming up next. So, I think, OKR's on a quarter basis, they give you something bigger to aim at. They give you a shared vision. Again, they are good for the team because they are pushing authority down to the team, gives the team a way of communicating with their stakeholders, their senior managers, they've probably got some, and I think this is powerful, better OKR's. And I'm also seeing the potential here and this is where I'm going to write about it in the new book, to throw away the backlog. I think we've got to the point in the world now where backlogs have served their usefulness. Very few teams ever complete their backlog. We just go around freaking guilty.
  • 21:48 Shane Hastie: I've seen backlogs that have got five years worth of work.
  • 21:52 Allan Kelly: Yeah. As a kid, I used to play Dungeons and Dragons, I'm sure a lot of your listeners did. And there was a magic item you could get in Dungeons and Dragons called a, bag of ever holding or universal bag. And you could put anything you liked in this bag and it just absorbed it and that's become the backlog of today. People just load them up and load them up. Anyway, I'm seeing a potential with OKR's to say, you know what? Forget about the backlog. Let's set ourselves some objectives for the next three months. We can talk about what might be objectives for future quarters.
  • 22:22 Allan Kelly: You can have a bit of an objectives' roadmap, but not too much detail, but for next quarter, here's our objectives now to hell with the backlog, once the quarter started, you sit down and you say, how are we going to achieve this? Now, if you've got an old backlog somewhere, you might go rummaging around and find some useful points. But to be honest, you sit down and you take a blank sheet of paper and you brainstorm, you say to meet this objective, what do we do as a team? And so I wouldn't say I'm yet at the point of saying, I love OKR's, but I've certainly gone through a bit of a conversion. I've been persuaded. They are, but not for the aspirational pointings for some other powers. I think they give us.
  • 23:01 Shane Hastie: So what does a good OKR look like?
  • 23:05 Allan Kelly: Oh, what's a good, OKR look like? Ooh, I'm going to be a mealy, mouth, manager and say that it is specific and it tells you what you want, and it's nonspecific and that gives the team flexibility to do what they need to achieve. So you need an outcome a benefit, a thing you want, and it would be nice to be specific about the outcome you want. But again, the whole thing, no solutioning in there, what you want is an outcome where the team who are building this can say, how can we satisfy that OKR? How can we satisfy that objective? And if you can, when you're setting them, come up with some key, not milestones, but things you're going to do to build towards that, these key results. And the more I look at key results, the more I think all the rules of user stories move across to key results. I think we can dispense with epics, I was never convinced with epics, anyway.
  • 24:04 Shane Hastie: You have to figure out what really an Epic is, but that's maybe a different story.
  • 24:08 Allan Kelly: Every story is an Epic until proven innocent. So I think a lot of the rules about user stories flow across to key results and so key results and objectives. They give you a flavour of why, they've talked about the outcome, but at the same time, they give you the flexibility to chase after this thing, it's a vision. It's a goal. Hopefully inspiring… When I get the perfect OKR, I'll let you know.
  • 24:33 Shane Hastie: So, if people want to continue the conversation, where do they find you?
  • 24:37 Allan Kelly: Alan Kelly is the name, I own the alankelly.net domain. So that's an easy one. And you'll find me on Twitter, @AlanKellynet. I've got a blog. I've got articles in so many places I've lost track of. So if you Google me, there's a couple of Allan Kelly's will come up, but usually fair to tell, which is the agile one.
  • 24:55 Shane Hastie: Allen, thanks so much for taking the time to talk to us.
  • 24:57 Allan Kelly: Thank you, Shane.

Mentioned:

Level-up on the skills most in-demand in 2021. Attend QCon Plus (May 17-28).

Validate your software roadmap by learning the trends, best practices and solutions applied by the world's most innovative software practitioners. If you are a senior software engineer, architect, or team lead and want to take your technical learning and personal development to a whole new level this year, join us at QCon Plus this May 17-28.

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Are OKRs valuable?

    by Ro Flemm /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Allan.
    You write in the summary on OKRs: "OKR's is the shared goals and the shared vision, and the fact that you will periodically sit your team down and say, what should our shared goals, our objectives, be for the next three months."
    In what way is OKR's different from the Product Backlog? And if it is, what is the benefit of defining such goals in a separate artefact?
    roland

  • Re: Are OKRs valuable?

    by allan kelly /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Short answer is OKRs are bigger than backlog items: backlogs are collections of independent trees, and work best when items are small. OKRs are forrests and work best when things are big and meaningful.

    However I really don't want you to have OKRs and backlogs, the two easily come into conflict. I would go as far as to say: throw your backlog away and drive all your work from the OKRs - a point I expand on in my book.

    OKRs provide the opportunity to return to "why" and ensure our work is driven by purpose. Too many teams have become backlog slaves and are running frantically to "just do stuff."

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

ß
BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.