In this episode, listeners learn from leading Agile practitioners about the benefits of Agile practice in a government context, keeping users at the centre and tackling myths surrounding its adoption.
The panel reflects on their experiences of adopting modern ways of working in government and discuss some of the key challenges they have faced in their journey to better teams and business outcomes.
Podcast host, Fleur Anderson is joined by:
- Julian Smith, Director of Member Experience, Mobility and Specialist Advice and Head of Agile Practice
- Andrea Anderson, Agile Practitioner, Department of Industry, Science, Energy and Resources
- Aaron Draper, Digital Partnerships, Planning & Governance, Enterprise Solutions & Technology, Australian Tax Office
- Shane Wheller, Agile Delivery Manager, Austrade
Listen to Episode 3 on:
Hello and welcome to the Digital Insights Podcast. A podcast brought to you by the Australian Government's Digital Profession. Keeping the Australian public service digital ready. I'm Fleur Anderson and I'm your host today. I acknowledge that we are recording this podcast on the lands of the Ngunnawal people, the traditional custodians of the land.
I pay my respects to their elders past and present. I extend that respect to all Aboriginal and Torres Strait Islander peoples listening.
Welcome to part one of this special podcast episode Adopting Agile successfully in government. In this two-part episode, we're going to take a deep dove with agile experts working with government agencies to tackle the big questions surrounding agile work.
Now it's 20 years ago this year that a bunch of software developers came up with The Agile Manifesto. So if you are looking for this original manifesto online, the really striking thing is, well, it looks really simple. It's even basic.
On the web page, it looks like it's been made by, you know, your immature web page designer down the road. Fancy it ain't. But over these past two decades, this short manifesto has spawned a new philosophy that practitioners call the agile mindset.
So to newcomers like me, it can almost sound like a new religion or a cult, even. However, some practitioners predict it could even spark an intellectual and cultural revolution on a scale that was sparked by Copernicus when he dared to suggest the Earth was not the center of the universe.
Sorry, I'm really excited today in real life in the studio, I have got four agile gurus from the Australian Public Service, so Julian Smith, welcome.
So Julian is the Director of Member Experience, Mobility and specialist advice and head of Agile Practice for the Digital Profession for the Australian Public Service Commission. So also joining us, we've got Andrea Anderson, Agile Practitioner, Department of Industry, Science, Energy and Resources.
Now we also have Aaron Draper, digital partnerships, planning and governance, enterprise solutions and technology with the Australian Taxation Office.
Good morning, everybody.
Good morning. And finally, we have Shane Wheller, agile delivery manager for Austrade.
Good morning. How are you?
I'm really well, so welcome to all of you. We're really excited to be able to talk to you today about agile methodology and application. As I said, I'm certainly no expert in this field. So when someone says a you an agile worker I like, of course I am, but I have no idea really what it is.
So anyone who has become curious about this thing, called agile working and agile mindsets, can probably attest that it can be a really hard concept to wrap your head around. It's even harder to define in some ways. So I was reading that in the early days, some practitioners resorted to the US Supreme Court's approach of defining pornography.
You know it when you see it. So I don't know. What do you guys think of that when you have to explain to your friends and family what you do with agile practice, what do you say? So Julian, can I start with you?
Yes. And I think you've really given a really great overview as well for just about the evolution of agile and particularly in 2001, where it kind of got kicked off at a ski lodge where a range of visionary software developers got together to flesh out a new way of developing software.
Now, when you look back at the history of Agile, however, it actually stems back quite a long time even from the early 1900s for so. For example, the Hawthorne studies, which were conducted by an Australian called Elton back in the early 1900s, explored what motivated people.
What are some of these stringent motivators that actually motivate people to do work? And as you can see through history, including through Toyota, with the Tibet, Toyota production system and other things that came through as well, including the evolution of a management practice, you can say a lot of trends happening.
And sometimes what I like to describe it as is the evolution of management practice. So the agile manifesto that got released in 2001 says 20 years old today. What's happened since then? So you can say that it's transformed not only house software development works and operates now.
Today, Agile is the de facto standard for how software is developed. You know, whether you look overseas at the big tech companies in Silicon Valley, you name the organisation, whether it be Microsoft or others, it's the foundation for how we work and operate in software.
But looking beyond that and looking beyond, particularly for government employees or for Australian public service, we say agile, becoming more and more commonplace for how we actually run and do business within government. A great example of this is the Agile Nations Charter.
They got signed by seven nations earlier this year, including UK, Canada, Japan, Singapore and others. So this is at the ministerial level and with I saw it as an avenue for not only developing software, but how government organisations work and operate and how to solve some of the most complex challenges we have in society today.
Now that might sound like a big, outlandish kind of thing, but it's when you look at how agile is kind of moved and pivoted. It's really transformed how organisations work and operate. Get getting back down to your original question about how would you describe it to others?
Well, from that, looking back at the agile manifesto, some of the transformative elements of it was about breaking down large projects or initiatives into more smaller chunks and pieces. But the real the real transformation that came out of it was putting people and customers first, testing your hypotheses with end users and iteratively and incrementally developing your new products and services. I quite like to think of it like a big soup. So for instance, if you own a kitchen, traditional projects, you'd have like a massive cauldron, right? And you try and add traditional projects, you're trying to add everything into the massive cauldron.
You'd add in all these different ingredients and you don't actually test with your customers until you finish making the soup. And as we do, they.
Like it or not. Yeah.
I get it. But that's exactly it. So another analogy in government is, say, the large projects. So sometimes we've launched these massive projects that can cost hundreds of millions, billions of dollars. And the interesting thing is, part of my job is going out and meeting with all the government agencies seeing how their projects and initiatives are going.
And as we know, some of these big projects, we know about Big Bang failures as well. Now, this isn't just something for Australia, but internationally too. So the way I like to kind of think about agile is. Testing soup as you making it so like when you're in the kitchen and actually Gordon Ramsay does this really well with his nightmare kitchen shows where actually when he's actually looking to start up a new restaurant, what he'll do is he'll make small dishes and he'll let you go out on the streets and test it with people on the street.
People in the community who test it with a target market small by size spaces before they even launch the restaurant. It's a quite similar thing with agile approaches to you. Want to start with a small soup, you want to sip it slowly, you want to adjust it as you go, and that's found through comprehensive research.
Now that type of management thinking has found not only to deliver more value quicker to the people we serve citizens, but also help us to reduce risk because if we make a bad soup, we know that citizens aren't shy of making their voices known.
So, yes, soup.
Well, that's a that's a really good analogy. So I guess, though, you know, there's some sort of rules to follow with making soup. And maybe, Andrea, if I can just talk to you about this for a minute. So you shared with me earlier a really interesting diagram that demonstrated some of the basic principles that now we don't need to go through all of them. But could you just sort of explain how that works and then why we have this absolutely confusing multitude of practices that, you know, I did this course on agile and I did this one blah blah blah blah.
But why is there not a definitive, agile practice? Can you just talk us through those that element?
There's the diagram that I shared with you was Ahmed Sidky's diagram, where it talks about the agile mindset is at its core. Or you might have seen an agile onion, which essentially books about the things that are so visible your agile mindset, your ability to think and be OK with ambiguity and to feel like I'm just going to approach this in a test and curious way. And then it's being manifested through and there are twelve principles associated with the manifesto. So there is some further guidance to unpick or how do we actually what do we mean when we're saying certain things within the manifesto?
And then that's manifested further in what we see, which more visible, which is your practices and the frameworks that you see in the certifications and other things that people desire to get. I think it's probably innately human for us to want to have a recipe that we can just draw upon, similar to your soup analogy.
We'd like to be given the big soup recipe to be told this is how you make great soup. But we all know that we don't live in a kitchen that has defined our ingredients and everything isn't the same every day.
We're dealing in real life where and as we've seen in the last couple of years, things have changed on a dime for our organisations, private and public, and we need to be free to feel like we can work within those principles and the manifesto to carve our own way forward.
And if we have a cookie cutter kind of recipe approach, then it's unlikely that we're going to feel like it can be adaptable or able to change as real life requires us to change. So there are a number of practices and things out there that are certifications and other things that will help you move towards that place of where you can start to leave the manifesto and feel like you can apply it in your own contextual environments. But that's not that's not your quick kind of silver bullet that will get you to a place of agility more sooner.
Really, it's a journey. It's an evolution, as Julian said.
Now I can say that Shane was writing some notes there, and he's claiming to be all shy now, but I think you want to add something to this.
Look, you know, everything you said is absolutely perfect. The idea of the multiple frameworks and different ways you can implement. Now we take him to take into consideration the context. The context is important. Context is basically everything. And that's why I don't copy and paste a framework might work over here.
But when you place it upon another team, that could be right next to each other because of their context, because of their culture, in the way that they have their place, and that we're going to use bingo words, they journey, you know where they are along that line.
Everything is about context. And that's why if you've got multiple frameworks, we can have them in our tool belt and say, okay, advise and potentially experiment and apply this thing from that framework, and it potentially could work well in this context. And so it's all about experimentation.
Okay, that's really interesting. So Aaron, I'll come to you now. Can you give us some real life examples? So, for example, you know, previously we've talked about Toyota and, you know, the old manufacturing line model, and now we've got a management model that's really been based around software development.
What does that look like in, you know, kind of compare and contrast it on an everyday level?
So I think everybody priorities really started to touch on this already. It's exactly as Shane said, it's that adaptability. When we look at agility, it's about that respond to market that respond to vision, that respond to what we actually have as a purpose. And going back to the manifesto, going back to that core belief back to those frameworks is really about that. We exist for a purpose in what we do in our roles as public servants. We're here, as you said prior, we're here to serve the public.
Agility is the mechanism which allows us to do that in a way that is efficient, is responsible and adaptable to change. So when we look at applying it in any part of our management structures, the way we work as an organisation or in our personal lives, it's about acknowledging that core belief that most people have within themselves that we need to be context sensitive and adjust to the environment around us. Organisation A Team B, Project C are all different. The agile mindset enables you to take the best way of doing things with that open mindset and apply that towards a known solution.
And that we can then work on iteratively and test with our market test with our clientele, which means us, which enables us to say all the way through the process. Are we doing the right thing? Not just are we doing the thing right?
Historically, we always ask, Are we doing it right? Are we taking the boxes? Are we meeting our governance requirements? Agility does that as well, but it flips the focus to say, Are we doing the thing that we should be doing rather than just doing the thing we think we should be doing?
So, you know. It gives us that opportunity to question that opportunity to re-evaluate and embed that in any of those frameworks which have come from the manifesto.
Just going back to the Copernicus example. So yeah, I think reading some of this material in the past it was that the organisation was the centre of the universe and that you had your customers sort of revolving around and they just sort of had to take what you were giving them in a static environment.
Whereas this seems to be more about, you're looking at your customer and understanding that they have got a lot of things going on around them, different organisations, yours might just be one of them and different life events. So I mean, I would be interested in any of your observations around this.
I know that there's kind of a trend now to provide services based around your customers life event rather than, well, we've got a new product. Would anyone like to ask Julian?
Yes. So it is a really key element to so. The Agile Manifesto, for example, talks about the number one principle that talks about the highest priority is to deliver for our customers. And so it's a really key component.
What we're seeing, probably more and more is particularly with that in mind, is that teams are actually bringing to the forefront, putting the customer first. And what I'm noticing that there's quite a lot of a trend, particularly towards focusing on empathy, focusing on engaging with our end users, focusing on understanding their needs across their journey.
One thing, one of the challenges I've seen in government in the past is that sometimes we're structured in a way along portfolios, programs and then projects, and that kind of breakdown sometimes doesn't enable us to see that the customer journey end to end.
A great example of this is some time ago I was working at a particular government agency, and our service spanned across four other government agencies. So it's something that touched on four other agencies and, you know, was plenty true of mobile apps and technology for these end users.
And the interesting thing, when we actually went out and engage with these end users, a lot of them didn't know about the other products and services available to them. So the interesting thing here, and the most valuable thing I've seen, particularly on my journey with Agile, is being able to validate our assumptions quite upfront and early.
So if we're looking to produce something, if we've got a really great idea, we would go to the end. Users would try and understand the full journey not only to the touch point where we are in terms of how the organisation structure because government is big, right?
It's got we've got so many, you know, we've got, you know, we've got, you know, over 127 government agencies, you know, we've got 150,000 employees, you know, we've got a very large agenda, but it's really important to collaborate, look at the whole system and say, what are some of the push pull factors that are kind of resulting in some of these issues that we're faced with what's actually helping and hindering and putting the users right at the centre? So that example I gave for that other government agency, it was really fantastic because we were able to sit down with end users, map out their journey and kind of discover what is the most important for them to solve for their current situation.
And Aaron. So I think that's interesting. Just coming back to that, now you're at the Australian Tax Office. Every Australian has to have an interaction with the Australian Tax Office, whether they like it or not. Can you like think about this in a really micro level, say, for example, you've got a person who might be a new job seeker? They might be thinking about maybe setting up their own little side business or trying to look for a job. How would you adapt the agile mindset to deliver those concrete things that they might want? And how would you discover what it is they want like on a really real life basis?
Yeah. So like most public service agencies that really serve the public, you know it's in the title. We do have a captive market segment. We can't attract new users the way that we would somewhere else. It's, you know, births, deaths and marriages. We're all involved in…
Death and taxes
Exactly death and taxes. I didn't want to go there, but they are inevitable. So rather than focusing on. You know, supplying a new thing, a new widget for the customer. We're competing in a space around their ease of interaction with our products we're competing with, like Microsoft and Google and Netflix for that customer experience.
So when we go back to your example, so when we're looking at somebody wanting to, you know, engage with JobSeeker, what we want to do is make that experience as easy to use and as seamless as possible. There's a tagline inside taxation, which is it just happens.
You don't actually need to do that much as an end user for the Australian taxation system. Now we have pre filling services. We have things which interact with other life events and other agencies that enable us to know what's happening to then tailor the experience to your need.
So taking the agile principles, it's allowed us to say we're going to meet client need in a better way, more reactively without it being a burden on the actual customer, the client experience, they're so. It just happens it.
That's the goal if we can make the system just happen. We've won. People are happy. I've been attacked for a very long time when I joined Tax. It was, oh, the big bad tax man. They want to come and take my money.
Now, when we look at the way in which we work and how our client perception within the market, it's now that it's easy for me to lodge. It's now easy for me to register a business. It's now about that ease of interaction and that stigma of big bad tax man hopefully has gone away for a lot of the market segment, and it's now about there is a benefit to me by engaging. So there is now a willingness rather than a reservation.
Shane, what's your thoughts on that?
Well, I think I was kind of thinking about the people that are listening to this and something concrete for them to take away. We know, we know you're out there, we can see you and we can see you in the trenches, day in, day out trying to make this work.
And you know, we've all been there. Everyone around this table has been there and we've got the scars to prove it. What we want to let you know is that just keep going like it's that resilience. It's it's having that saucepan of agility and popping in the ingredients that you need to in your context to make it happen. And there's absolutely no right and wrong. Don't think that, oh, that's not agile. We're not going to, you know, those those types of that. Don't worry about that. Just commence commence the journey of continuous improvement, throwing a bit of human centred design.
Grab, grab the DTA process, do a bit of discovery and do a bit of alpha beta, go live, you know, whatever it takes, but don't think that there's any right or wrong. And and just keep the user at the centre.
So it's kind of it's kind of almost common sense, isn't it, in terms of prioritising what you're going to do next and you do it to comment on that. So you're at the Department of Industry, you must be dealing with businesses doing this sort of stuff all the time.
Oh yes, the industry's an interesting beast. I suppose it's the result of many machinery of government changes over the years, so it is a conglomeration of various business areas all there for the general public to know how to build a business themselves, to conduct themselves in the in the right way in our business and grow our
economy. I guess certainly to bring on some of the things that Shane and Aron have talked about. For me, a lot of working in an agile way is really about creating opportunities for that fast feedback loops to test and learn continuously and hierarchies in government.
That's just how we've worked over the last 20 years, and I think we've still got a long way to go to help us feel comfortable by working around or within those hierarchies so that we can get access to the customer can ask those challenging questions about Why are we doing this?
What is this for? Who is this going to benefit? And so that we can bring that customer interaction closer and that not necessarily just the general public, but some of our customers are actually internal government departments or staff within our own organisation.
And I think we've learned over time working it out in our kind of government silos that we have to throw things over the fence to the next team as it progresses along the flow of work. But if you come to your workplace, and certainly this is just how taking on chains talk about continuing, it doesn't matter. There's no right or wrong way. But if you approach any of your projects in a way that helps to create opportunities for those kinds of questions to be asked about, how are we going to towards what our success criteria?
How do we know that this is going to be useful? It's not good enough now for us to be have projects that are within time, within budget and scope. It's the customer satisfaction that's at the centre and you can you can probably exceed a few of those things and still have a very successful project.
So there's a different way of us measuring projects now that I think we need to turn our mind towards. That success isn't just the iron triangle of projects and really about that modern management approach. Working in an agile way is also about looking after the humanity of the people that work within our organisations and respecting that they're human beings with goals and desires and a working environment that that helps them to work to their most productive. So I'd like to that's I think some of the practices and things that we can draw on from the frameworks help to change the conversations within our internal team.
So that we're not just talking about building the project or finishing the project, we're actually talking about what's working well in the way that we interact in my day in my team. And what else could we try that would make my workplace a little bit more fun, a little bit more challenging, a little bit more interesting and creating that approach within managers and leaders in our organisation to ask those questions by default and to approach their teams instead of, I'm going to tell you what to do, but actually, maybe I should ask the team what they want and get them to design their own future and the way that they approach their work.
I think we've forgotten how to do that in our hierarchies. So certainly that's some of the things I would like.
Yes. So I mean, obviously, we're all met well, most of the time mature adults who run our own lives, who make our own good decisions and prioritise our own. You know the things that we need to do each day.
So why does that have to stop when we get to work? So Shane, what's your reflections on that?
So if you're if you're a manager out there and you're still managing by the green light, it's on teams or the green light that's on WebEx or whatever software that you have with your remote teams and requiring them to sit there for eight hours a day.
We got to we got to introduce some contemporary management techniques to your to your playbook. I'm afraid those days of well gone that just aren't even relevant anymore. The best way to manage knowledge workers is to give them a piece of the pie, so bring them into the tent to have them.
Part of the planning process and system is the way in which you deliver, such that it increases the likelihood that your team is going to stay. We want we've invested so much money in the knowledge, skills and training that we can't have them go off to the next job.
So send them on courses and don't worry about what they do. If we train them up, they might leave. Well, how about we invest in more of trying to keep them systemise the way in which we keep them with the way we do that?
And you know, it's just contemporary management. You can have a job or you like you can you can have your waterfalls or you like, you know, the rich got the right approach for different applications, but it's just about contemporary management of a modern workforce, basically.
But yes, I really love that just to echo some of the thoughts, you know, particularly about the human way that we manage our teams internally and also to provide a bit of a story as well. Because at an agency, I won't give the name of the agency, but we went for a customer first approach and it really transformed so much in terms of putting people first. And so, for instance, meeting with the end users and going through this journey, we were able to identify and help solve some very complex issues and also address some of the most challenging issues that we have in government.
I think working in government. What I've noticed in working with a lot of different agencies and working talking with a lot of different agencies is the passion behind what a lot of people have. Because working in government, we're here to solve some of the most wicked problems we have in society, whether it be homelessness hospitals, whether it be unemployment covered to name a few. So really, putting people at the heart and at the centre, we're able to not only have a more humane way of working internally within teams, but also externally. Just saying when I visited recently, for example, was sick.
And just to feel the vibe on the floor like I was walking around with a team. We're going through a bit of a tour and I saw people with massive smiles on their faces and saying, What what's up with you?
So what to see? I been there, were all engaged and, you know, they're really kind of celebrating their experiments and the wins. And it was just the vibe that you feel in a workplace where you can empower your staff, where people can master their craft and when they're aligned to purpose.
That autonomy, master and purpose is a powerful mix.
And that's the compound effect. Shane's talked about this as well as we want to empower our knowledge workers. We've talked about client management, understanding client. That's not just about building a better product, but it's about doing it in a better way.
If you understand that vision, if you understand that purpose, you're going to be more motivated. You're going to do things in innovative ways, which will lead to the next new thing, which then has that realisation for client for customer.
So it's not about doing it for them, it's about doing it for everything that we do. And back to Shane's point, management's got to change the way we work has got to change the hardest part.
Shane is fist pumping in the air at the moment.
Yes, Shane, and all this is passion is shining. It's not about shifting them. It's about shifting us. And the biggest change in shifting to an agile way of working is that change in mindset and allowing other people to make decisions other people likely know more than you do.
That's a fact. We need to acknowledge that in the way in which we manage our teams and let them do the best work that they can. Don't check timesheets. Talk about outcomes, not outputs. Why are we doing it?
How are we doing it? Not when is it due? And if we can do that, then we're starting to really think about the benefit of agility. End to end.
So it's absolutely yes, you can do it. And can you do it when we've got a fixed scope? Yes, we can do it. However, along the journey along the process of delivering it as you bring the people into the tent that you're delivering to, because that's how we work together now.
We bring everybody together and we show the thing more often they will come along the journey to say, Well, hang on. You know what? Now we've seen it. We probably don't need that feature anymore. Oh, really? But it's in the scope of work.
It's in the project plan. We have to deliver it. Let's have a conversation about that. And so you've already triggered the trade off of the scope. So yes, you can do. You can work in an agile way in a 15 hour fix constrained environment within the government.
You got to taste the soup, see if it's still soup by the end that you want it and not a bread roll or a salad. Because if we asked for a salad and we start making a soup, that's a problem.
You're listening to the Digital Profession Insights Series. Be Digital Ready and join the digital profession today. Visit Digital Profession Dot Gov Dot Au for more information.
So that's a good segue way. Then to another thing I wanted to ask you about myth busting. So you've talked about scope and budget. I mean, these would have to be some of the common myths. Wouldn't that around agile?
Practice, there's no control over the budget, there's no control over the timing, the deadline where I've always all my paperwork that shows what you're doing and how come you're not following this plan that we worked out and we agreed on two years ago?
Let's open it up. I can see that you're all rolling your eyes at me, but I know who's first.
Everyone is lining up.
So yes, some myths. So let's do some myth busting. I feel like we need some music. You know, so one of the interesting one and just hearing from the conversation today is about business outcomes. So we're hearing a lot about autonomy.
You know, teams and sometimes the natural thought is, Oh, wow, you know, these teams are going to go wild, they're going to go off on all different directions. But the important thing here is also about setting up some of those guardrails and particularly having clarity of purpose and vision.
So one of the things one of the interesting things that I've been doing recently with another Australian agile Craig Smith, is we've been working on engaging with other governments actually in the US government, and we went to do some presentations in India and in New Zealand and elsewhere.
We've been going exploring what are some of the key issues and where we go. We commonly find similar types of things as well. But one of the key elements that we've kind of unearth is making sure to have a very much a clarity on what is value and value can come in a couple of different sense.
Firstly, it as a citizen value, which is the ultimate where we want to put the citizen at the heart. But because we live in a democratic system, we've got governments who set policy, we've got election cycles as well.
Policy comes in waves and cycles as well. So the important point here is that in terms of achieving business outcomes, it is very much core and centre. But from a business point of view too, it does make sense.
So I'll just give it one quick other story. We, as part a previous roles role is to engage with all other government agencies and those one initiative that kept on failing. Now these are all in public media. You know, it's not nothing sacred here, but you're after you.
So we'd go to them and say, you know, how are you going? And anyway, the money kind of stacked up and. And by the end of it, it finished. And I do this calculation and I kind of add it up, add it up, shockingly to about 27 Titanic's in today's dollars.
Now the interesting when you look at the research and the kind of, you know, some of the benefits is that agile is not only more beneficial, for instance, from the Standish Group, who did a research report over 20 years of projects that actually study projects around the world for 20 years.
And the that agile not only was good for small projects, so it's actually 300% less likely to fail. But the interesting results that they found was that for initiatives over 10 million, it was actually 600% less likely to fail.
And that's because of being able to test assumptions up front. So instead of sinking 27 Titanic's, we're able to test and be able to. So it makes business sense. In other words, we can said, drive common purpose among your staff.
That's a really common purpose. Set those guardrails, enable them to innovate, but yet also test our critical assumptions and enable experimentation to do so.
So that's a good question. I mean, it does sound too good to be true sometimes, doesn't it? With agile like, you know, we're all going to experiment in small sprints and we're going to get it all right. But inevitably, there's going to be failure.
So how do you communicate to the people up the chain and the people down the chain? OK, we've had a failure. It's fine. Or do we not? We don't say the f word.
Can I ask a question? Yes. Would you like to fail in three years or would you like to know that we're not going to achieve that target now? Because that's what agility gives you. It gives you the ability to know earlier that we're on the wrong path and we can pivot.
There's cheering and jubilation at the table.
So fast fail, early fail. Often, you know, like you don't want to have a car crash, but it's okay if you trip over. And that's kind of the messaging that we want. It's part of the experimentation. It's part of what needs to happen only through failing, only through trying something new do we find the new way to do things. And that's at the heart of what we talk about. You go back and look at the principles. That's what we're here to do. We're able to react to the things which change around us, whether that's others or ourselves, acknowledge that and improve from that.
So what other myths do we need to bust out? I'll go to Andrea now?
I think there's a certainly there's a myth that agile helps you move faster and do deliver faster and you can do more with less. And certainly, that's not been my experience, and I don't know any project that would survive.
If you could maybe staff your team with fewer people and expect that things will happen and you could plan it to the nth degree and still be successful at the end. Certainly, in my experience, agile working in an agile way in an agile project involves planning along the way.
So it might feel like you don't do so much up front because you're testing with small hypotheses. But when you're potentially seeing the output of something, you're going to a sprint review and starting to see some of the product that the team is delivering.
So maybe to some people, it might feel like, oh, this is so much faster than in actual fact, you're just not marring yourself in a months or 20 weeks of requirements gathering, whether you're ending up with documents and documents of things that you ultimately hand off to somebody to go away and build the ideas or certainly the myth that needs busting is that most definitely you can start to receive working product. That's part of the principles is that you will actually start to receive any non software delivery space that I would start to see drafts.
I'll start to see skeleton of documents and things actually coming to fruition. They may not be perfect because Don is so much better than perfect. So there is a feeling, certainly for some people, that agile will give me stuff faster when in actual fact, you just making the right thing at the right time and you're making sure that you're only doing enough work. one of my favourite principles is simplicity is the art of maximising the work not done, the amount of work not done. And that's I certainly adhere to that at home and in work because there's no use spending time on a document that's going to be shelf wear and need to be revisited or uplifted in six months time because somebody some exec wanted it. It's doing the right amount of work right now. And if that means it's a whiteboard or a picture of a whiteboard with a bit of a roadmap on it that highlights what's up next, then that's enough.
And I think we have this illusion of control that's given to us by some of the maybe more traditional processes in the past where by giving X document and it's taken me a whole week to do it. By doing that, it actually equates to something when in actual fact, it's shelf where and it's something that may be one or two people might skim through.
Look, the other one was too many meetings, too many meetings, OK? We do have a range of five meetings over a two week period, one meeting we do each day. The idea that each of those have got agendas that flow the work through to each fortnight and we deliver something of incremental value at the end of each fortnight, which then decreases the likelihood of long project failure. So we're increasing the likelihood of success.
So the manner in which I talk to fix is always about risk because that's what they know and understand. So what we're trying to do is decrease the likelihood of project failure, increase the likelihood that the users have something that's fit
for purpose and to potentially be more responsive to the business. We don't do agile for agile sake. We do agile to be more responsive to the business as it changes because our environments change constantly. The idea So there is a lot of meetings if you continue to do your traditional meetings.
So the idea of all the agendas in the agile stack. And we're talking scrum is that we can actually drop those other meetings that we've had in favour of doing the same old, same old and flowing the work through because over time, once they become the culture of the team, they do it on a daily basis and do it by themselves. I'm playing on a podcast about teams delivering products to production so that can be utilised by the business to grow the business value. So you know, they're on autopilot, but we don't have those extra meetings that we need to worry about because it's all in the process.
And extensive meetings? Absolutely. When we do a product, what refinement, for example, there are a lot of stakeholders attending that. The idea there was to have a shared understanding of the work that needs to be delivered in that cuts down the amount of ask and whites that we have.
Ask him, why ask him why? So we go to a meeting. We have a Two-Way conversations. The whole conversations change what we said in the meetings. So they were communicating that to others. Then the power around owning information is vested in the small group of people that become the leaders.
This sort of notion that we, we we're still being organised as a command and control top down world. If you remove that and you have the shared understanding from those large meetings, you give the opportunity for all this ask and waits to be dealt with inside the tiny box.
So over time, you get less people turning up because their value proposition for tending decreases over time, they are not as important as they thought they might have been, for example, in adding value and therefore that meetings become less and less and less to that small group of people that understand the problem that are helping deliver the solution. So you actually become more efficient over time.
You've been listening to the Digital Profession's Insights podcast. Find the Digital Insights podcast on all major podcast services. Stay up to date by following us on LinkedIn or Facebook. And of course, if you haven't done so yet, join the profession today, you'll get access to exclusive learning opportunities, accreditation of your skills, and the chance to connect with peers across government. Visit Digital Profession Dot Gov Dot AP for more information. See you next time.