Silicon Review names ZXM as one of the 50 Smartest Companies for 2016

We are excited to announce that we have been named by the Silicon Review as one of the 50 smartest companies for 2016. Its been a fantiastic achievement and we would like to thank all our wonderful staff and clients for helping us achieve this fantastic recognition by peers in our field.


The Silicon Review is the world’s most trusted online and print community for business & technology professionals. Its community includes thought-provoking CEOs, CIOs, CTOs, IT VPs and managers, along with jillions of diverse IT professionals. It is the pre-eminent platform that shares innovative enterprise solutions developed by established solution providers and upcoming hot enterprises emphasizing as a neutral source for technology decision makers. This is the place where senior level IT buyers and decision-makers come to learn and also share their experiences in regards to products, technologies and technology trends. They get an expert advice to manage their people and advance their careers.

Here is the link to the article

Full Article

The digital economy has transformed the way both small and large businesses operate. Competition, government policy,
industry standards and regulations all requires smarter, faster, leaner ways of working. As such, digital transformation is a major challenge faced by both commercial and government enterprises seeking products and services that are easy to use, easy to access, and delivered in the most effective and efficient way possible to their stakeholders. There is also increased pressure on budgets to “do more with less” and achieve quicker returns on investments. Customer expectations of products and services are also rising – wanting higher quality products, faster service, and a more personal experience from corporates and government alike.

To meet the challenges that modern organizations face, Zen Ex Machina (ZXM) was created in 2011 by its three founders with the aim to help clients solve the complex business problems with solutions of elegant simplicity. With headquarters in both Australia and New Zealand, ZXM facilitates enterprises to move on from traditional development methodologies by helping them to adapt, change and improve starting from utilization of resources, focus on creation of value, to meet the demands of the digital age and become faster, smarter and more agile businesses.

Simplicity; ZXM lives by it
Simplicity is at the heart of ZXM’s core values. It uses 21st century, digital, agile techniques to understand complicated business problems. Beginner’s Mind and minimalism is always at the forefront of the company’s thinking and agile methods are at the core of its practice. With a highly collaborative and disciplined approach to Agile methods like Scrum, Kanban and Lean, ZXM helps businesses transform its practices quickly, with minimal waste, and with high repeatability. As a result, their client’s learning and delivery gets faster and better, and organisational practices get improved continuously.

“No one at ZXM is ever happy with just ‘good’ – it has to be ‘better’. This is what we always strive to deliver.”

The ZXM Skill Set
ZXM’s core competencies lie in the use of behavioral change methods, design thinking, continuous improvement, and digital agility.

The Transtheoretical Model (TTM) of Behavioural Change by Prochaska and DiClimente helps ZXM to step organisations through a pragmatic sequence of change creating long-lived behaviours and promoting cultural change.

Design Thinking focuses ZXM consultants to engage in curious, critical and creative dialogues in collaboration with their clients to solve complex problems. By using empathy for the context of a problem, insights are drawn from the context space with rational analysis of the traceability of solutions back to the problem space. In essence, design is used to match people’s needs with what is technologically feasible and viable as a business strategy.

ZXM uses the Deming Cycle (P-D-C-A) as the foundation of its delivery – an iterative approach used to introduce continuous improvement from continuous delivery. Specifically, ZXM uses P-D-C-A in the form of Scrum – one of many agile methods – as the basis for all consulting products and services regardless of whether they are software-based or not – from management consulting reports, to user-experience advice, strategic reviews and agile coaching.

Better, simpler solutions through close collaboration
ZXM employs Agile, Lean and UX methods, such as Lean UX and Design Thinking, as multi-disciplinary tools to bring clarity and transparency to customer problems because while delivery can be agile, products may not be fit to engage if user-experience is not considered. Also, without Lean, the speed to market for a digital business product or service may suffer.
For its government clients, ZXM uses Lean to bring transparency to their value chain, UX Story Mapping to help identify pain-points with existing government services, and Scrum to rapidly develop and deliver digital, lower cost, citizen-centric solutions. For corporate clients, regardless of size, using Lean UX and Scrum helps to collaborate on producing simpler solutions that delight and engage with fast feedback loops. The result is high quality that is faster to market and can meet immediate customer needs with less cost. Close collaboration is the key to ZXM’s approach. The goal is not only to collaboratively help solve problems, but also to learn to apply these tools themselves in a sustainable way. ZXM’s objective is ultimately to teach clients how to improve their digital business products and services for themselves

A natural at being distinct
ZXM is a pioneer in the field of application of behavioral science to assist its clients with agile adoption and digital transformation. Culture is a key perpetual issue for many clients and the Company’s unique blend of frameworks from social and organizational psychology and behavioral change help alleviate the problems of adoption in a way that is sustainable, long-lived and unique amongst its competitors. These frameworks underpin ZXM’s consulting services from Agile Coaching and Training to Digital Agility and Project, Program and Portfolio Management.

The company’s client spectrum includes a wide range of the Government businesses such as Australian Taxation Office, Australian Institute of Sport, Australian Communications and Media Authority, Australian National Maritime Museum, Department of Health and Ageing, Department of Industry and Innovation, Comcare and commercial business like eBay, Origin Energy, Superchoice, The Web Showroom and Cupid Media.

Rapid growth but untouched values
ZXM is present across Australia and New Zealand and works with clients in Sydney, Melbourne, Gold Coast, Canberra and Wellington (NZ). The company’s growth has doubled the past year and has also doubled its consultant base to meet an expanding demand for agility in consulting services and in agile transformation. ZXM is advancing but still seeks to stay true to core values of simplicity, agility, collaboration, sustainability and value. The company looks forward to expand its presence across the Asia Pacific region.

Agile Product Ownership and the Role of the Business Analyst

As part of the IIBA stream at the recent Australian Computer Society Conference #ACSCanCon16, I explored agile product ownership and the role of a business analyst when they move to an Agile project. I thought about how business analysts play an important role.

In traditional waterfall projects they usually act as the link between the business units and IT, helping to discover the user needs and the solution to address them. In Agile Teams however, there is no business analyst role.

As an enterprise agile coach, I was recently working with a BA who was faced with this situation when his organisation was undergoing and digital transformation. We explored what happens to the business analysts in Scrum teams to work out what was the best way he could develop his agile capability and contribute to the Team.


View this presentation on Prezi!

Like other specialist roles, the work of a business analyst changes in Scrum. I discussed with this BA some of the options for business analysts working in a Scrum team and how their knowledge and skills present an opportunity to play a vital role in product ownership. Business analysts tend to have an intimate knowledge of the product plus strong communication skills, and this lends itself to a shift into product ownership. So we explored two option:

BA as a Team member

Business analysts working as a Agile Team member become part of a cross functional team and often take the lead to help their peers refine the product backlog and understand the functional specifications for the product. There is however a shift in emphasis from writing about requirements to talking about them. As a team member, the BA’s first priority to to helping the Team achieve the sprint goal and therefore the BA contributes by tracking down answers about features, cross pairing with developers to learn more about how the solution works, assisting in testing and/or writing test cases and scenarios as well as completing design and functional documentation about the solution.

BA as Product Owner

Another option is for the Analyst to act as product owner for the  team, working with product management and business stakeholders to translate the vision into product backlogs for the teams. The Business Analyst as product owner is often a natural extension of a more senior business analyst’s role. But it usually implies change: A business analyst turned product owner should now own the product on behalf of the organisation, and be empowered to decide what the product should look like and do, and the ranked order in which functionality is to be developed. The Business Analyst  usually also has to learn new skills including understanding what users need, business value and how their needs can be best met, refining the product backlog and writing user stories.


BA’s place in agile teams:

  • Shift from making deliverables and producing upfront requirements
  • Shift from projects and temporary team membership
  • Focus on users and needs over system functionality
  • The “brains” in the agile team to contribute to solving complex user problems
  • Contributing to product development and product evolution
  • Team member, with collaborative, collective “product ownership”
  • Team empowered to deliver high value solutions to solve user problems

Beyond Lean UX: Making Enterprise Agility and Scrum more User-Centred

We get the best feedback from working software over documentation, says Alistair Cockburn when commenting recently on the Agile Manifesto.


View on Prezi:

And while some look at enterprise use of Lean UX to make us more customer focused with feedback loops, what can we do instead to make Scrum at scale more user-centred? How can we better leverage its powerful P-D-C-A learning loops at scale as an integral part of continuous delivery?

And check out Steve Granese’s awesome sketchnote of the presentation!

Dealing with Dysfunction: using couples counselling patterns to manage team conflict

Is your team dysfunctional? Is their behaviour likely headed down a path that will destroy their productivity and collaboration? If they are, what are the war in signs and, importantly, what can you do to help mitigate their behaviour?


Asimov’s Laws of Robotics help man and machine get along. So, where are the laws that stop teams from hurting themselves either by action or inaction?

This presentations looks at the Gottman Method – a psychological research-based approach to creating stronger relationships – and an example of its use with Asimov’s Laws of Robotics to deal with agile team dysfunction, strengthen collaboration and help build happier teams.

View on Prezi now!

The 8 Elements of Agile Coaching

Lyssa Adkins has a well-known coaching model amongst agile professionals. I saw it last year when I was at Agile 2015 in DC.

Lyssa Adkins coaching model

When I saw Lyssa presenting this model in a role play session up on the stage, though, I was struck by what I saw. Having a psych background, I saw her helping someone to resolve pain in the example what was presented to the person on stage. Immediately, I rushed to jot down what was in my mind.

What are the 8 Elements of Agile Coaching

Recently, at Scrum Australia, Mia Horrigan (ZXM Agile Coach) presented her experience as a “Scrum Mum” and described the pattern we’re now using to frame our coaching. The model is based on 8 elements:

  • Mentor – Develops ‘how to’s
  • Consultant – Develops frameworks
  • Coach – Develops and sets shared goals
  • Counsellor – Develops structures to resolve disfunction
  • Change Agent – Focusses on embedding change
  • Facilitator – Supports a formal outcome without advice
  • Lean Leader – Develops people
  • Trainer/Teacher – Focuses on skills development through instruction


Unlike Lyssa’s model, we’ve done away with the domain elements of technical, business and transformation mastery, and instead developed additional ‘hats’ as part of a contingency-based coaching model after Feidler’s work on contingency-based leadership. This enables the model to apply to any domain whether the coach has a technical background or whether the coach is coaching in technical, design or business environment.

In aligning with Alistair Cockburn’s new thinking around the Heart of Agile and Shu Ha Ri Kokoro we’re proposed that the 8 elements make up the Ri stage with Kokoro as the Elite Agile Coach stage where coaching competencies and behaviours simply boil down to:

  • Listening with empathy
  • Asking deep questions
  • Empowering people
  • Enabling people to act
  • Reinforcing agile behaviours
  • Increasing insight

Using the Model

Out of recent teams’ Retrospectives on client site, I’ve been gathering the coaching group together and looking at the problems, issues and capability growth opportunities we’ll tackling next Sprint or two. These go into the coaches’ Retrospective, where we assess the root cause, determine which coaching element out of the 8 best applies to the context, and then which coach has the greatest strength in that area. That coach then leaves to plan and remedy and/or support the issue at hand.


Rather going on gut feel, this model has given our coaches a language they can use for discussion as not only a shared way of addressing issues but also to recognise strengths in each other’s coaching styles.

Confessions of a Scrum Mum – how the short term heroics don’t scale

As an Agile Coach and Chief Scrum Master responsible for 8 teams in a service delivery program, when things went wrong, I found it really tempting to get in and try to patch and fix things, direct the teams and make decisions for the Scrum Masters and Product Owners. In this type of role, I drew heavily upon my Program Manager background and found that when things were going wrong, I would fall back into directing teams what to do, sorting out issues for them and making decisions. I spend my life as a soccer mum outside work hours and now I found at work I had ultimately become the “Scrum Mum”.

At the recent Scrum Australia conference in Melbourne, I presented my lessons learnt on how to evolve from this Scrum Mum anti-pattern towards Agile coaching using a contingency based approach depending on the environment of the team/s. This approach helps guides the team through coaching and mentoring towards self organisation, empowerment and cultural change.

In this presentation I highlighted different scrum master maturity models and demonstrated how at an enterprise level, the Scrum Mum is an anti-pattern that isn’t sustainable or scaleable and whilst the team/s may be successful in the short term due to the heroic efforts of the Scrum Mum and a few good individuals, this anti- pattern will ultimately lead to stagnation by the teams

Moving to Agile: What’s the difference between a project manager and a product owner?


When making the decision to adopt an agile method like Scrum, invariably the question about existing roles arises. In particular, I find that the question of “where do my project managers fit in” is one asked most often.

Comparing Project Manager and Product Owner/Product Manager roles

While the Project Management and Product Owner roles are quite different in their focus, there are many similarities between them.

Project Manager Product Owner/
Product Manager
Primary concern Create “a temporary endeavour undertaken to create a unique product, service, or result” [1] Create a framework built on the need for a product to “satisfy a want or a need” [2]
Focus When will it be delivered? ·Why are we delivering it and to whom?
  Schedule driven ·Value driven
  Plan creates the cost, schedule, estimates Valued features drive estimates and then schedule
  Try to predict what users need Find out what users want and adapt to their evolving needs
  Optimise utilisation of team members through phase based and sequential activities Team self-organises to optimise its work Sprint to Sprint supported by a Scrum Master
  • Risk and issue management
  • Resource management
  • Scope management and change management
  • Stakeholder management
  • Communications management
  • Balance time, cost and quality
  • Manage the product delivery until its handed over to its business owner
  • Product vision
  • Delivery roadmap
  • Benefits/outcomes realisation
  • Understand user needs
  • Understand stakeholder needs
  • Scope management and change management
  • Stakeholder management
  • Communications management
  • Deliver the product
  • Manage the product and improve upon it until it is no longer needed

The function of good project management doesn’t go away

In Scrum, the gaps between a Project Manager and a Product Owner are filled by other roles.

Scrum projects eliminate the role of the project manager, but that doesn’t mean a team can get rid of the work and responsibilities of that role. Since self-organizing teams are at the core of Scrum, a great deal of the responsibility previously shouldered by the project manager is transferred to the Scrum team.

Without a project manager to assign tasks to individuals, team members assume the responsibility of selecting tasks themselves.

– Mike Cohn [3]

The tasks of project management don't disappear, they're just done by other Scrum roles

The tasks of project management don’t disappear, they’re just done by other Scrum roles


Whether you’re title is Project Manager or Program Manager the tasks you normally do day-to-day don’t go away when your organisation transitions to Scrum, but the focus of why the project is being done does change. Suddenly, delivery becomes about continuous delivery of value. For business, stakeholders and end-users this transformation provides better outcomes for everyone.


– – –

[1] Project Management Institute (2004). A Guide to the Project Management Body of Knowledge: PMBOK Guide. 3rd Edition. Newtown Square, Pennsylvania, Project Management Institute, p. 5.

[2] Kotler, P., Armstrong, G., Brown, L., and Adam, S. (2006) Marketing, 7th Ed. Pearson Education Australia/Prentice Hall.

[3] Cohn, M (2016) Which course is right for me? Online at:

What’s the difference between Waterfall and Scrum?

“But isn’t that just doing mini-waterfalls?”, asked a recent attendee at one of our Agile Essentials courses.

Scrum requires the team do all the same type of activity they used to do in a Waterfall environment — analysis, design, build and testing their product. I showed the person the faster feedback cycles and the anti-patterns of waterfalling Sprints, but it still wasn’t enough for her.

Don't Waterfall your Sprints

A comparison of Waterfalling Sprints versus Scrum’s Sprints

What I needed was a side-by-side comparison that illustrated how each of these two methods handled different aspects of project management and delivery.

Waterfall Scrum
Schedule driven Value driven
Plan creates the cost, schedule, estimates Valued features drive estimates
Development is phase based and sequential Development is iterative and incremental
Focus is predictive Focus is adaptive
Demonstrate progress by reporting on activity and stage gateways Demonstrate progress by delivering valued features every two weeks
Product quality at the end after extensive test/fix activities Quality is built in with upfront standards
Batches are large (frequently 100%) Optimises smaller, economically sensible, batch sizes for speed of delivery of valued features
Critical learning applies on one major analyse-design-build-test loop Leverages multiple concurrent learning loops
Process is tolerant of late learning Work is organised for fast feedback
Handovers between analyse-design-build-test phases with knowledge stored in documents Cross-functional team with knowledge of the product invested in the whole team through shared experiences

For me, the main difference in comparing the two methods is:

  • Scrum is value driven, where the plan is formed around the question “what is the most valuable item we can deliver today”
  • Waterfall produces a plan from which costs, schedule and estimates are created

If I wanted to deliver value to clients and stakeholders, Scrum is the method I would choose.


ZXM named in the top 25 Most Promising Agile Solution Providers APAC 2016

We were really excited and humbled to be named in CIO Outlook’s top 25 Agile Solution providers in APAC 2016. CIO outlook has gained recognition within the tech industry  and its magazine leverages its extensive network of leading technology executives to share their experience and the best practices with the Enterprise IT community in Asia Pacific countries.

ZXM was shortlisted to be part of the magazine’s annual special edition on “Agile Solutions” after its research team analyzed the offerings, top management and reputation of over 800 companies providing Agile Solutions and Services. With the help of CIO outlook’s advisory board consisting of top CIO’s and Senior IT managers from medium to large companies in APAC, around 80 businesses were shortlisted, all of whom are leading companies in Agile Method. The final list of 25 Most Promising includes emerging companies that are providing cutting edge solutions to enterprises in APAC.


Here is the full article.

Agile methodologies are widely accepted as one of the best approaches to project delivery. An organization that has undergone agile transformation finds increased harmony among stakeholders, resulting in improvements in overall productivity and company’s profitability. One of the most interesting changes that agile brings about is the positive effect on  team morale. Given this heightened interest in agile project delivery and project management approaches, there is a dire need for service providers who can understand and respond well to the business needs of individual companies as well as government agencies.

Our goal is not only to collaboratively help clients solve their problems, but ultimately to teach them how to improve their digital business products and services by themselves

Eying unexplored opportunities in the agile consulting industry, Mia Horrigan, Matthew Hodgson and Kai Koenig incepted Zen Ex Machina (ZXM), an agile management consulting services company, to help clients solve some of the most complex business problems and create elegant digital products and services in the process. Mia Horrigan, CEO, explains, “ZXM deploys 21st century’s digital, agile techniques to understand complicated business problems—an approach which is faster to market and can meet customer expectations in minimized cost.”

Founded in 2011, ZXM helps customers in their transition from traditional development methodologies to agile methods that meet the demands of the digital age and become “faster and smarter”. ZXM employs Lean UX and Design Thinking methodologies as multi-disciplinary tools to bring clarity and transparency in solving the problems clients face. For the clients from government sector, ZXM uses Lean  to bring transparency in their value chain. The company uses UX Story Mapping to identify pain-points in existing government services, and uses Scrum to rapidly develop and deliver digital, lower cost, citizen-centric solutions. For its corporate clients, ZXM uses Lean UX and Scrum to collaborate on producing simpler solutions that delight and engage with fast feedback loops.

With its headquarters in Canberra, Australia, ZXM uses behavioral change methods, design thinking and continuous improvement approaches in delivery. Using the Transtheoretical Model (TTM) of Behavioral Change, ZXM helps clients to transform organizations through a pragmatic sequence of changes to create long-lived, sustainable behaviors and promote cultural change. By using  Design Thinking, ZXM  engages curious, critical and creative dialogues in collaboration with clients to solve complex problems.  ZXM also uses the Deming Cycle (P-D-C-A) as the foundation of its delivery in the form of Scrum—an agile methodology. It forms the basis of all the consulting products and services, including management consulting reports, user-experience advice, strategic reviews and agile coaching. Matthew Hodgson, CIO, says, “Close collaboration is the key to our approach. Our goal is not only to collaboratively help them to solve their problems, but ultimately to teach them how to improve their digital business products and services by themselves.”

Some of ZXM’s elite clients include Federal Government such as the Australian Taxation Office and Department of Health, utilities including Origin Energy, digital business, start-ups and many more. Its founders are acclaimed international speakers who regularly share their experiences in digital transformation and enterprise agility at conferences across UK, USA, Germany, Australia, New Zealand and China. Kai Koenig, CTO, adds, “We have doubled our growth last year and also doubled consultant base to meet the growing demand for agility in consulting services and transformation.” By staying true to its core values of simplicity, agility, collaboration and sustainability, ZXM aims to expand its reach across Asia Pacific region.


Specialist Team Members within a Scrum Team – Testers

In my previous post on Business Analysts as Specilaist Team members within a Scrum team noted, individual team members may have specialised skills and areas of focus, however accountability to deliver the Sprint work belongs to the Scrum development team as a whole.

The whole team is responsible – whether its support for testing built into the features or more people testing, it is not done until it is done. Testers within a Scrum development team help ensure that the right product is getting created and that the product is being made right.

The tester would support the Product Owner by:

  • Writing/reviewing acceptance criteria for each product backlog item (user story)
  • Write/review testing scenarios for the user stories
  • Meeting with clients and business to establish what is needed, what they are wanting to achieve and how that may impact current systems, processes and users

The tester would contribute to the delivery of the product increment by[1]:

  • Creating test cases
  • Automating test cases
  • Executing acceptance criteria
  • Smoke test UI/regressions (previous sprint).
  • Exploratory testing to find bugs that no automated test will ever find
  • Pairing on development to improve understanding of the code

Scrum teams are intentionally small. Most have a high ratio of developers to testers. Even though that can account for most of your testing time, successful teams have flexible members and testers should have a willingness to step outside their circle of comfort.

Before the Sprint begins, testers can help the team by validating the product (looking at the design and talking through the feature to make sure it makes sense), identifying product risks and system risks before they become issues and making sure that the feature will support test automation.

During implementation, testers make sure the tests are getting written from the start. The best way to do that is to meet with the developer and product owner before any work is done so that the tester can provide their input for what will be tested[2] and also start working on BDD/TDD scenarios for testing to make sure all acceptance criteria are verified and reflect end user’s behaviour and interaction with the system.

Testers help the team to understand what the system state is at the beginning, the trigger for the test, and the criteria for the test with enough detail to know which business rules are being tested. Writing the code behind the tests, such as step definitions for “Given, When, Then” cucumber scenarios, will help the team get to ‘done’ but also help them understand what is happening when the step runs.

Pairing on development and testing strengthens both team members. With people crossing disciplines, they improve understanding of the product, the code, and what other stakeholders find important.