I’m sure we’ve all read recently of more and more organisations choosing to ‘go’ agile through ‘shock and awe’; aiming to complete the transition to “better ways of working” in a matter of weeks. In some instances, we’ve even seen the organisation issue new employment contracts and give staff 48 hours to accept them or leave. I’m not kidding. All in the name of ‘agile’. What happened to “individuals and interactions” being the most important value? It makes me want to weep; but instead I’d rather do something about it.

What if there were other ways to introduce such changes to large organisations? What if there didn’t need to be a large formal change management plan? What if it didn’t need to be force-fed at speed? What if we could help those affected by the change co-design the change? What if we could embrace uncertainty and try small incremental changes, gain feedback and insights? You know, what if we could apply lean and agile value and principles to the way we shift to more lean and agile ways of working? It seems kind of obvious, but it’s not that common.

My name is David Morris, and I am a lean change facilitator. Join me as I share my journey from seeing the darkness in my consultancy ways and the dawning realisation that following a plan-driven approach to implementing feedback-driven practices was just plain bonkers. Together we will try out some techniques for applying lean, agile, and systems thinking to large-scale change. You should all come away with some actions you can try out straight away.

Looking to move to Continuous Delivery? Worried about the quality of your the code? Helping your developers understand clean-code practices and getting the right testing strategy in place can take a while. What should you do to control the quality of the incoming code till then? This talk shares our experience of using PRRiskAdvisor to gradually educate and influence developers to write better code and also help the code reviewer to be more effective at their reviews.

Every time a developer raises a pull-request, PRRiskAdvisor analyzes the files that were changed and publishes a report on the pull request itself with the overall risk associated with this pull request and also risk associated with each file. It also runs static code analysis using SonarQube and publishes the configured violations as comments on the pull request. This way the reviewer just has to look at the pull request to get a decent idea of what it means to review this pull request. If there are too many violations, then PRRiskAdvisor can also automatically reject the pull request.

By doing this, we saw our developers starting paying more attention to clean code practices and hence the overall quality of the incoming code improved, while we worked on putting the right engineering practices and testing strategy in place.

By working with some of the most successful tech-product companies, I realised that code is NOT an asset, it's a liability. We should strive hard to minimise code. In 2011, when I started to hack on ConfEngine, I questioned my belief in TDD. I had also started playing around with APL style Array-Programming and Functional Programming. I felt, may be, I was getting a bit too dogmatic about TDD and automated tests in-general. As a thought experiment, I decided to build ConfEngine without ANY automated test. At first, it was really scary not to have the safety-net of automated test (something I took for granted for almost a decade.)

As I scaled ConfEngine without any automated tests, I had certain interesting realisations:

• How to embrace Simplicity and Minimalism WITHOUT automated tests
• Why Throwing Away Code frequently helps you achieve a better decoupled-design and how this helps in better experimentation
• Fear of Refactoring WITHOUT Tests is over-rated (Good IDE and safe-refactoring techniques can take you a long way)

ConfEngine grew from a pet-project to a 8 member product team. It has over 60K users and has done financial transactions worth over half-million USD. And we continue to push forward without ANY automated tests. Its not perfect, but it has certainly helped me challenge my dogma around TDD.

Background: In 2001, I stumbled upon the Test Infected paper. For the next 2 years, I struggled to really apply the test-first concept on real projects. Finally in 2003, I felt that I had fully internalised TDD and was able to apply on almost all projects. Then I started playing around with FIT and FitNesse, using ATDD on some of the projects. In 2006 I published "Avatars of TDD" paper in which I explained various styles of TDD and its design implications. Until 2011, I was a very big advocate of TDD, ATDD and BDD. I still like those practices, however I would not recommend it in all projects.

How do you deliver a big policy outcome that normally take 6 months when you only have weeks?

An early election was called and we faced having to develop two sets of a comprehensive policy documents -- the red book (left-wing) and the blue book (right-wing) -- to brief an incoming government in 8 weeks. We were caught by surprise, the normal lead time were gone, and news about policy commitments came faster from TV and social media than traditional internal sources. This was a non ICT business team who hadn't done Agile before however we felt given the time frames, it was the best way to approach for such a high profile project.

Come and learn about and application of Lean Kanban and how we delivered the outcome through:

• engagement with the executive to share drafts of chapters, then gather and incorporate feedback in short iterative cycles to improve transparency and alignment.
• team design in non-software environment
• limiting waste and duplication
• visualising flow
• coordination of “Scrum of Scrums” key daily meetings to promote collaboration, visibility and transparency
• supporting team leads to coordinate the collaborative, dynamic planning process, prioritising work that needs to be done against the capacity and capability of the team
• providing visibility and transparency of work in progress and flow and share this with other teams and stakeholders.

Mia will discuss how she addressed business agility through working with a Portfolio Management Office (PMO) to assist the Incoming Government Brief (IGB) task force to work iteratively and apply agile practices to draft and deliver policy documentation to articulate the details and costing of policy initiatives from each of the major political parties in the lead up to the Federal election. This involved working with Executives and Business stakeholders within the policy domain during a hectic period where policy could change or be adjusted and costed daily as policies were revealed by each side during the campaign. The policy team need to improve the enterprises business agility to respond to rapid change and this involved working with the leadership across 12 branches to align iterations of draft policy documentation over an intensive period. (the taskforce was pulled together to deliver the IGB over 8 weeks). Specifically, Kanban and Lean were chosen as the method for delivery.

This approach resulted in executives having earlier visibility of the approach and content of the IGB and improved quality of IGB by reducing the risk that significant changes being identified late in the delivery. The Teams were focused to delivery higher value work more efficiently, while being transparent about delays to lower value activities. The success of this initiative in a non-ICT environment has promoted the PMO to look at other business areas to implement Agile to develop an Agile mindset across the Agency.

Evidence-Based Management (EBM) is a framework to help measure, manage, and increase the value derived from product delivery. EBM focuses on improving outcomes, reducing risks, and optimising investments and is an important tool to help leaders put the right measures in place to invest in the right places, make smarter decisions and reduce risk using an iterative and incremental approach. This empirical method alongside the agile principles and values of Scrum enables successful steps of change for the organisation.

Organisations invest in agile processes, tools, training, and coaching, but how much are they getting back? Has product delivery improved? How much happier are users and the business customers? Are employees empowered and enabled? Traditional metrics might give you insight into improvements of operational efficiency but the real conversation is about the value created for your organisation by the improved processes. Without measuring value, the success of any agile initiative is based on nothing more than intuition and assumption.

Mia will discuss Evidence based management and how this empirical process can help agile transformations measure and manage the value derived from the transformation initiative. Mia will focus on the 4 Key Value Areas: Current Value, Ability to Innovate, Unrealised Value and time to market and how these contribute to an organisation’s ability to deliver business value.