Isn't Kanban just post-it notes on walls? Maybe they're powerful ways of working that can be applied to any process.

Come and learn the power of Kanban and Lean through a fun, interactive simulation involving pizza and teams.

In this workshop, we'll be making (paper) pizza in teams, defining the workflow you create, and learning how to use WIP limits, and other key metrics, to see which pizza team can deliver the most pizza!

What if everything we thought we knew about agile was wrong?

The nature of agile continually changes, which means its analysis must also keep pace. Agilelistics is for practitioners, thinkers, and theorists of agile.

The data analytics revolution and agile metrics gather around agile teams, has become agile's new language and currency.

What is Agilelistics? Agilelistics is the practice where metrics is used to drive the entire product development cycle. The use of just-in-time metrics to drive rapid, precise and granular product iterations. In an organisation who uses metrics, where everything from performance to usage patterns is measured. Every single decision is used by the development team is based on metrics.

Steve Morgan helps you to decipher the statistical data, and to use it to uncovering agile's hidden truths.

• How do I know my team is improving?
• How many story points should my team tackle per sprint?
• How can I fix my team’s estimations which are currently not accurate?
• Is velocity a true measure of an agile team’s performance?

Through a blend of entertaining storytelling, agile metrics and analysis, This Agilelistics session will answer common questions about measuring agile team performance.

A resilient organizational can not only adapt and respond to incremental change but more importantly, can respond to sudden disruptions and also, be the source of disruption in order to prosper and flourish.

The traditional risk management approach focuses too much on defensive (stopping bad things happen) thinking versus a more progressive (making good things happen) thinking. Being defensive requires consistency across the organization and this is where methodologies like Plan-Do-Check-Act (PDCA) come in. However, PDCA approach does not bake in the required progressive thinking and flexibility required for a fast company organization which operates in a volatile environment.

Professor David Denyer of Cranfield University has recently published a very interesting research report on Organizational Resilience. He has identified the following four quadrants across to help us think about organizational resilience:

• preventative control (defensive consistency)
• mindful action (defensive flexibility)
• performance optimization (progressive consistency)
• adaptive innovation (progressive flexibility)

In this talk, I'll share my personal experience of using this thinking to help an organization to scale their product to Millions of users. I've dive deep into how we structured our organization for Structural Agility and how we set-up a very lightweight governance model using OKRs to drive the necessary flexible and progressive thinking.

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.

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.

UX is about discovery. Agile is about delivery. The two worlds seem so very far apart. How then, can you make the DTA's Digital Service Standard work for you without creating silos or creating more quality gates and just doing iterative waterfall?

In this talk, we'll demystify the DTA's Digital Service Standard and take a deep-dive into a pragmatic re-interpretation of UX and Agile in terms of:

• What does the DSS really ask of agile teams?
• User-centred agility
• Product management lifecycle vs project management lifecycle
• Lean UX at scale
• Discovery as an ongoing practice for agile teams
• Advanced practices for UX in agile
• Integrating the DSS into teams' Definition of Done
• DSS and working with SAFe
• Assessing a program of work against DTA's DSS

Am I biased? … Maybe a little… I guess I am just a cheesy guy!

They say French is the language of love., but when I say “I love Agile” ... so much, it’s not just because I’ve been helping organisations adopt agile and thrive using them. I honestly feel agile offers tremendous value to any product development program.

Please consider the following statements:

• I’m passionate about agile.
• Every day you learn something from someone, if you listen.
• What I most like about working agile is being part of a team.
• The hardest thing about doing something, is knowing when you have finished doing it.
• My favourite question is “How’s life?”
• The biggest flaws in my life are my greatest assets!
• It’s fun to see how far you can push the boundaries.
• Laughing offers a way of getting through things.
• I remember the day, I decide it was time for a change.

So yes, change is hard; I get it; it’s human nature. But if you’re willing to let it, agile can be pervasive in your organisation, given time to take hold. Everywhere I’ve used it; most people love it.

The key to agile is remembering that people are at the core of everything.

Agile approaches don’t just let you react to change - they are designed for it.

Make your people and processes work for you — don’t be a victim to the one true way of doing something. Embrace transparency, inspection and adaption. No more ‘death marches’. No more spending a ton of time up front in analysis paralysis. No more delivering defective products. Being agile is continually evolving how you do things.