 We've now got David Scott who's talking about applying agile in real-world scenarios. Alissa apparently was going to jointly present it but she's had to be a late withdrawal unfortunately. So I'm looking forward to this talk. Obviously it's certainly uptake of agile methodologies and government is certainly a growing area there. And I think it'll be interesting to talk about particularly applying that in that risk-averse government context as well. So I'll hand over to David now from Doc House. Thank you very much. I hope everything's working well. Yes, it's absolutely right. It is a really interesting space to be in in terms of applying agile and understanding those limitations. And that's particularly what Alissa was keen to share today. So she does send her apologies to everybody but she's given me quite a bit of information to pass on to everybody. So we'll jump straight into it and start talking about applying agile in those real-world scenarios. It's in particular relation to a recent project that our team delivered for VCAT. Alissa is program manager there at VCAT across all things digital. And so she's the person who has to go and convince the board and convince the procurement departments to operate in an act that their projects will operate an agile way and to trust the processes and to trust her team that deliver them. And Doc House were fortunate enough to work alongside them and deliver a recent project for them. Talking about agile, we'll know it. You know, we'll think we know it. It's nothing particularly new here to ourselves and to this audience. But particularly what are we talking about? What am I talking with you about today? It's agile in the context of the real-world constraints of that vendor-client relationship, the government sector and with budget and timeframe limitations. There are all things that we have to take into account in day-to-day with almost all of the projects we deliver or the engagements we get brought in on. And often there can be big expectations with agile in it. You know, people have heard a lot about it and keen to operate in that way, but there can be misaligned understandings of how to apply it in reality. You know, when we look at a lot of projects and engagements with fixed timeframes, fixed budgets, fixed scope, that doesn't equal agile. And so what can we do to make it work for us and deliver the best results? I mean, ultimately, we realize and we know that there aren't endless budgets and endless programs of work. If you operate in that space, fantastic. Good luck and I hope you have a really good time. But we do have to take into account that define our engagements with our clients. So what are the organizational factors that might limit adoption of agile? And this is really where Elisa was keen to share with the audience some of those things which she has worked through in her experience in bringing agile on board and delivering successful projects. You know, public and private sector agencies are looking to agile as the new standard. You know, as its principles and the terminology becomes part of the product development vernacular. But if you wrongly apply it in environments with the inability to adapt agile, it can have detrimental effects on trust and throughput and the ultimate success of the project. So bringing on stakeholders who haven't had in-depth exposure to agile is a particular challenging government where the traditional view of rigorous, risk-averse project governance focuses on defining scope and a solution up front. So how do you build trust and confidence in the process? So some of the factors that limit adoption is around that not having a full understanding and not having been through it before. So there are opportunities to improve the understanding of agile within government at a leadership governance and procurement level, particularly at initiation, beginning with procurement. The requirement, it's often an articulation of a fixed deliverable or fixed deliverables. Example, in this timeframe for this budget, you'll get this. But this approach isn't aligned with agile or the broader innovation methodologies which involve discovery, data analysis, feature prioritisation and feasibility assessments to determine features and then plot a roadmap out for their release. So it'd be great to change the conversation to value from deliverables to value. What will deliver the greatest value without getting locked into solutions at the initiation stage? They're the conversations which Alisa had focused on getting through and working with. VCAT are quite mature with agile now so that they're quite successful across a number of projects and programmes of work right through the organisation. And so in the traditional view, agile is sometimes equated with a lack of rigor being perceived as too loosely defined. But conversely, what we have is actually quite rigorous processes so that we get to, in the product sense, release early and released often so that we get to see the delivery of the project and the features take shape as we go. And that's what builds trust and confidence in the process. So a lot of people are asking, what are the benefits of adopting it? What are the benefits of running programmes and projects utilising these methodologies? And as I said, because of its transparency and values-driven analysis and emphasising time boxing work to deliver proofs of concepts or MVPs, we mitigate those risks which are concerns and people have been concerned with up front and concerns around time blowouts, budget blowouts, these kind of things that it enables you to deliver better services at pace and that's something which particularly now the government is keen to achieve. And many organisations are keen to achieve with COVID impacts on business and having to change, pivot and deliver new services or services in new ways and do those quickly. And so putting the time in up front to understand value creation we're mitigating those risks of not delivering those transformative outcomes that we're hoping for at the start of the project. So how do we apply it? A large part of the success that Elisa and the VCAT team went through to get buy-in for this project was educating their stakeholders. There's a lot of education and work which went on to support the organisation, the stakeholders and write through the organisation to understand the agile methods so that they're adopted and through the continual demonstration of their vision the value that they're delivering and progress then throughout delivery they could see the trust in the process which we're constantly showcasing, playing back progress reports so that they could understand it and build the trust and confidence in the project's design delivery and then ultimately what was going to be released and then continually released thereafter. So then we get into some of the nitty-gritty about how we do it how do we operate in this way to deliver projects. Then in the context of this particular piece of work between Doghouse and VCAT which is common for a number of engagements it's where integrated as part of a project delivery team so that we have Doghouse team members working together in a larger product team alongside VCAT's subject matter experts, business analysts, program leads, delivery leads so we're integrated within and form one large delivery team and so that we have the trust to work together we utilise things like radical transparency and it's just about being open and honest and we know we're usually working to a fixed top line spend so we have an open and shared view of the burn down or spend of that budget we're not hiding any numbers or waiting for end of sprint time reports end of month invoicing to know who's been working on what for how long and we're integrated into that project team to get the best results and that openness and honesty is a huge part of that and so the team needs to understand what all those expectations are we have clear expectations set so that between vendor and client we know how each other is engaged and what the premise of the commercial agreement is so from a delivery team point of view from a vendor to technology provider point of view the development team needs to know and understand that their whole days are being bought by the client as part of this relationship the whole sprints are being bought so that if they need to spend some time brushing up their skills or their knowledge on a particular framework that they might not have used recently that time that they might spend in the morning getting back up to speed on some view JS that goes against the project it's that they understand how the team's time has been procured and what that relationship is and we're embedded so that the client we're buying sprints of our time together and we're delivering throughput so people are sick or they have time off we manage the impact to the project velocity and we make up the missing days and we have through that we get trust and it's trust that it trust creates trust so that the vendor in VCAT and the client trust the delivery team that they've engaged to deliver the value and then they need to know and they trust that they need to understand that features will come but we need X number of sprints to build velocity to get there so then once we start getting to that velocity we can see that there's progress being made and that can be shared through the organization a little insight into how we do some of that is through sharing it's pretty old, pretty simple but this isn't just time tracking from within the doghouse team it's open and shared with VCAT so day to day I can have a live view of expenditure and burn down what are we planning to spend per sprint per day and what are we actually spending what are we actually consuming in terms of that burn down of that budget who is away and what days so where do we make up time and through that what are the results so you get efficiency when you collaborate together and work in this manner we get the tailored outcome of a product which is ultimately suited because it's been released early and often and the whole organization have been able to see it take shape and you end up with ultimately the most business value so the product, the site took over two years to deliver from start to finish, from VCAT's point of view from design through to delivery the website component, the transformation of the website took approximately about nine months and as you can see some of this information from Alisa or VCAT they're very happy with what they've received through that delivery it's given their customers a simpler a simpler, faster self-service experience their customers are able to find what they're looking for a lot more easily they're reducing the volumes on their call centres and through this through the course of this engagement we were hit with the changes of the working relationship through COVID and having working on site with the integrated VCAT team to being dispersed and everybody working remotely and not only that the huge impact that VCAT received in having all of their cases now heard online and the site, the new site that they've launched has been able to support that and provide their customers with much better ways of finding the information they require for their trials and reducing the volumes through to the call centre at the same time has been quite an amazing thing to deliver so with that let's say thank you for your time and Jeff, if there's any further comments or feedback that have come through anyone's got any that are welcome to come forward? Yeah, we've got a question from John about how do you tightly control scope so you don't add any more value than you really need and therefore control expenditure and meet expectations? It is a very good question, a very good point because we're trying to seek it through this style of engagement seeking to deliver as much scope and value as we can we are over the course of a project which might take say nine months in this case like I said we take a few sprints to get up and running and we can start to see what kind of throughput we can get it really takes probably at least four sprints before you start to see what your value is and you need to understand what scope is achievable and ultimately we know we're not going to be re-engaged if we can't deliver an ultimate deliverable of a high functioning, very usable website covering a lot of the features which were agreed up front but not contracted so the contract is for time and for time and for the team so how not to deliver too much scope it's really key for your top project management BA and probably top technical team to understand the efforts in the key features and particularly with a product owner to prioritise the key features that are going to be absolutely required and then what might make up an MVP in this context and anything beyond that sort of our benefits over and above so real prioritisation of your key features would be the big thing there Well we're running close to time now well thank you very much for that talk David that was really interesting and I think relevant as most government agencies and departments are now in some form or another going down that path with Agile some are more advanced some are still learning but I think it's really eliminating talk and really good to keep that discussion going between the government arena Thanks again Thanks everyone