Whitepaper – Agile Adoption in Government

What are the key considerations when choosing to adopt agile methods in a government context?

This whitepaper by Zen Ex Machina is aimed at government senior executives and managers. It examines the benefits of adoption of Scrum to both initiate new projects and rescued stalled ones within a government context.

In this whitepaper, Zen Ex Machina articulates:

  • The ANAO’s factors in planning and approving projects as they relate to using Scrum.
  • Why projects using Waterfall are more likely to fail than Agile projects.
  • The benefits/outcomes can be realised through adopting Scrum.
  • How Scrum aligns with Prince2 requirements.
  • How Scrum’s key processes can increase transparency and reduce risk.
  • Impediments to adopting Scrum.

Importantly, this whitepaper articulates how to get started with Scrum, including planning, governance and building requirements.

If you work in government, you can receive your copy of the whitepaper by completing the the following details:

Who *should* be your Product Owner?

Who should be your (Scrum) Product Owner?

I’ve had a number of these conversations recently with small, boutique software development agencies and even design companies with UX expertise. Typically, the conversation goes something like this:

  • The business stakeholder or client is the owner of the product, so they should be the Product Owner
  • We’ve got a Product Manager, so they should be the Product Owner?
  • The Development Team is supposed to self-manage, so they can just share the Product Owner role
  • Decisions about the scope and what the Development Team should work on is far too important for just one person, so we should have a committee make the decision.

The Scrum Guide (2013) is pretty specific about what the role of Product Owner is and what it does:

“The Product Owner is responsible for maximizing the value of the product and the work of the
Development Team. How this is done may vary widely across organizations, Scrum Teams, and

“The Product Owner is the sole person responsible for managing the Product Backlog… [the role requires] is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner [1].”

The implications are significant. Ultimately, it means managing the Product Backlog in such a way so as to achieve balance between optimisation at the delivery (Team) level and the vision of the product.

Different Product Owners

Client as Product Owner

In my experience, when push comes to shove, and the end of funds is near or the project is running out of time, a client won’t throw Scrum aside and push for more features. I’ve often heard them say, “you’re agile, so that means you just have to learn to adapt”.

  • Advantage: Clear view of the vision
  • Disadvantage: Doesn’t care about your Scrum process. Won’t truly understand balancing technical features and technical debt over features and functionality.
  • Result: Features! Features! Features!

Business Analyst as Product Owner

A senior B.A. is a whiz at managing scope and interpreting clients’ needs. Unfortunately, they are often too low down the pecking order to be given responsibility for delivering an outcome.

  • Advantage: Product Backlog Lumberjack!
  • Disadvantage: Often not empowered.
  • Result: Wait until I go ask someone and then I can tell you the decision.

Scrum doesn’t say where that vision needs to come from, though. It could come from the client, a Product Manager, a Program Manager or the executive leadership team in a large enterprise.

Project Manager as Product Owner

A Project Manager’s focus is not too dissimilar from a Product Owner’s. He maximises the ROI of a project, manage stakeholders and communication, its finances and changes to its scope.

  • Advantage: Often have the power to make decisions
  • Disadvantage: May not be technical enough to create balance between the technical needs of a product and the needs of the requirements of clients. May tend to blur the line between the “what” and the “how” and micromanage the Development Team to deliver an outcome. Scrum key meetings may fall by the wayside as a result to make more time to code.
  • Result: You should be coding not being in meetings so much!

UX Designer/Architect as the Product Owners

I came from a UX background. It influences my Scrum practice quite heavily in terms of optimising the Product Backlog so that it delivers value to end-users. As such, when I perform the role of Product Owner, I’m always conscious of building a product with a user-centred vision, and balancing good UX with technical features and the “nice to haves” that clients ask for.

  • Advantage: User centred perspective.
  • Disadvantage: Like a BA, may be too low level to be empowered. May “gold plate” the UI and not care how long it takes the Development Team to deliver.
  • Result: This would be good for users, but the Project/Product Manager/Client has overridden me and wants more features.

Product Managers as Product Owners

I find that Product Managers, like Program Managers, are just too high level and too concerned with larger things to get their hands dirty at a local, Development Team level. Their responsibilities often mean there is little time to spend in key meetings relating User Story level details to a Development Team.

  • Advantage: Have the vision and are empowered to achieve it
  • Disadvantage: May not know how to translate that vision into items for the Product Backlog. May not have the time to dedicate to collaborating with the Development Team to deliver the outcome because they are spending more of their time with senior stakeholders.
  • Result: Here is the big picture, now just do it!

Line Managers as Product Owners

In an organisational context, Managers can be quite effective Product Owners. They already have experience telling their teams what to do. Empowerment is an important key aspect of being a good Product Owner, and in environments with an existing hierarchical structure, this is one of my favourite patterns.

  • Advantage: They are empowered to make decisions.
  • Disadvantage: May be too used to micromanaging their team.
  • Result: Agile aside, what do you need to deliver?

So, who could be the Product Owner

My favourite Product Owners are senior BAs with enough referent power on the client side to help shepherd them to good decisions regarding the vision, enough expertise to manage the scope of the Product Backlog themselves to deliver a high-value product, and with experience with Scrum so that they respect the process.

Ultimately, there is no best person for the role other than someone who is empowered to make decisions, balance the short and longer term vision of delivery, and has experience with Scrum sufficient not to throw it away when things get tough.

Hierarchy and Product Owners

But sometimes one Product Owner is not enough. And when there is a whole program of work and many teams, what happens to the Product Owner? Can he make the same decisions independent of other Product Owners?

Program Management and Product Owners

In SAFe, the high-level vision comes from the Program Manager who collaborates with a number of Team-level Product Owners.

SAFe's Product Manager to Product Owner model

Product Managers have a number of Product Owners

This model is quite logical in an enterprise with an existing management hierarchy, particularly where the vision of the product is made at a level higher than the Team.

Chief Product Owners and Local Product Owners

In LeSS, that superordinate view of the direction of the product as a whole comes from a (Chief) Product Owner who then engages Area Product Owners.

The LeSS model focuses on a Product Owner Team

The LeSS model focuses on a Product Owner Team

In more decentralised Team environments, an Area Product Owner (APO) specialises in a customer-centric area and acts as Product Owner in relation to one or more teams for that area. An Area Product Owner does the same work as a Product Owner but with a more limited, yet still customer-centric, perspective.


Understanding the governance between the strategic, tactical and delivery aspects of a program of work is key to understanding who is the best person to be the Product Owner. Ultimately, it can be anyone, so long as “the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog [1]”.


The Development’s Team’s focus is often to build the product right, making sure it works and the code is of good quality. The Product Manager’s focus is on achieving the vision, but not necessarily on the detail to make it work. The clients’ focus is all about features features features!

Ultimately, the role of the Scrum’s Product Owner is the focus point of all these conversations. It has to be one person, not many, otherwise decisions may take too long, the focus might lean too much toward the higher (product management) or lower perspective (team’s delivery), or the governance watered down so that no one is the “go to gaol” person when things go poorly.

Who ever you decide on making your Product Owner, ensure they are:

  • Empowered to make decisions.
  • Can be pragmatic in creating a balanced outcome between the vision and delivery.
  • Know and respect Scrum, so they make it all work through collaboration with the Development Team, the Scrum Master and the customer (who ever that might be).
Team, Product Owner, Client collaboration

Team, Product Owner, Client collaboration



[1] Schwaber, K. & Sutherland, J. 2013. The Scrum Guide™ The Definitive Guide to Scrum: The Rules of the Game. p5.

Growing Pains – Scaling Agile to achieve greater capability in service delivery

The team I was working with had a “great problem” – more work than we could deliver. However this success brought mixed blessings as the strain of growing so quickly was starting to show. We had a backlog of work, process issues, resourcing and quality issues and a lot of knowledge residing with one or two of the original start-up team who were now single points of failure.

The innovative, “can do” attitude of the start-up company was still there but we were having growing pains. We knew that what we were experiencing in our market (Australia) would eventually be seen in our USA market if we didn’t find a solution to our growing pains.

We looked to Lean and Agile as a multidisciplinary approach to achieving an effective product strategy, development and delivery capability that could be scaled to the whole organization.

As a result of our optimization for lean delivery we had an empowered team, improved quality, know velocity and capacity and an organization that is learning to deal with changes and project complexity. In the short term we achieved greater transparency of projects, increased collaboration and knowledge sharing across teams and the team now had a better understanding of the “what” and definition of done and a process to handle unknowns and respond to changes. Projects are now managed in programs of work and we now have a product and service delivery roadmap to ensure enterprise aims for product development are linked to implementation strategy and delivery.



Adopting Scrum helped to improve delivery capability and enhance product co-development partnerships and decreased the risk of failure to deliver the Program of work in a timely fashion. This was done through employing a number of methods and techniques, including working collaboratively with stakeholders and end-users, simplifying governance and increasing accountability and employing iterative methods, rather than a ‘big bang’ approach. Encouraging frequent inspection and adaption, teamwork and collaboration between the project’s members ensure that knowledge and skills were shared within and across teams as the process scaled from project delivery to program and portfolio level delivery.

The artefacts and learnings from the Australian pilot were adopted by the global PMO and we are now helping to roll out this framework to other regions. Once clients become a program of work, we had a scalable and proven method to ensure we continue to deliver a quality outcome.

An important part of our aim was to optimize for lean delivery. Scrum’s processes are explicitly engineered to identify and decrease waste and the organization was able to ensure that through the PRINCE2 governance framework the project was empowered to be responsive to changes in its environment so that delivery aligns with changing user, stakeholder and organizational needs. This ensured that all of the Program’s features delivered were useful and of high-value.

Agile adoption & helping to change organisational culture

This presentation given at LAST 2014 (Melbourne, Australia) and Agile 2014 (Orlando, USA) outlines ZXM’s behavioural approach to changing culture to become more agile based on Hofstede’s cultural factors and the Transtheoretical Model of behavioural change.


You can view this presentation on the Prezi website: prezi.com/gimawcukycsx/agile-adoption-helping-to-change-organisational-culture


Session activity handouts (PDF 108KB).


How to Teach your Team Scrum in Three Months

We tend to think about agile as a software development approach, but it has applications to the business as it can aid the improvement of business processes and give non-technical staff an approach that help them gain the efficiency in projects that agile has delivered in the software development environment.

At the recent Australian Computer Society Agile Special Interest Group, I shared my experience in implementing Scrum for a services team with a backlog of projects, and within three months we were able to take the team from Unconscious Incompetence to Unconscious Competence and provide them with increased efficiency and a simplified process to deliver both their Business as Usual (BAU) work as well as IT project initiatives.

We used a psychology based model to implement Scrum. In psychology, the four stages of competence, or the “conscious competence” learning model, relates to the psychological states involved in the process of progressing from incompetence to competence in a skill. It suggests that individuals are initially unaware of how little they know, or unconscious of their incompetence. As they recognize their incompetence, they consciously acquire a skill, then consciously use that skill. Eventually, the skill can be done without consciously being thought through, and the individual is said to have unconscious competence.

The team always seemed to have a “backlog” of work that never got done. The main issues were:

  • No collective process for them to process business user requests
  • New work coming constantly coming in from the business
  • Team not sure of which work was important, urgent or ranked higher
  • No collective processes to handle BAU as well as project work
  • Team working in three streams of activity As a result, they started a bit of each project but never quite got anything finished.

This exposure to agile in the business setting had a flow on effect to IT projects in that when the product owners needed to work with the technology team on backlog grooming and user story development, they have a shared understanding of the process and this helped improve the collaboration between business and technology and enhanced clarification of specifications and requirements.

Outcome at the end of the three months:

  • Better understanding of commitment to take on a product/story in a Sprint
  • Greater visibility of BAU capacity
  • Collaboration and pairing across old silos occurred to complete tasks
  •  Not silos of 3 streams — a single team with a single, shared vision of how to get their work done

Why use a behavioral based learning approach?

  • Demonstrates how to retrospectively assess  story complexity to improve capacity planning of  teams
  • A framework for coaching agile teams based on  observing their behaviour to identify their of learning
  • It is the behaviour that needs to change to ensure the agile approach is successfu

Lean Coffee

Lean Coffee is an structured but agenda less meeting that allows participants to gather, build and talk.

Our implementation of Lean Coffee with this client was a way to informally discuss what was important to the team and look at ways to improve our efficiency, effectiveness and processes within the service delivery team.

[Source: Lean Coffee from Mia Horrigan ]

How does it work?

  • We spend 2 mins writing down topics people want to discuss
  • We spend 2 – 5 mins minutes letting people explain their topics (15-30 secs each)
  • We vote on which topics to discuss in what order. Each person gets 3 votes
  • We start talking. We let the conversation run for 5 minutes per topic, at the 5 minute mark we take a show of thumbs (up, down, neutral) to see if we want to stay on this topic or move on

It’s really that simple. The power is that we have a list of topics everyone at the table is interested in and is motivated to discuss.

Benefits of Lean Coffee:

  • Talk about what is important to my team
  • Team decides how long we discuss each topic
  • Sharing experiences and challenges
  • We are solving problems together
  • Collaboration and team building
  • No preparation required
  • Free coffee on the boss!

The Lean, Agile PMO

Presentation at the Australian Computer Society 2013, Canberra Australia.

In a modern world of agile processes and self-managing teams, what role does the traditional Project Management Office (PMO) play? What does an agile PMO look like and why would you want one? Is PRINCE2 still relevant in a Scrum world? How do you bring these worlds together and bring traditional project managers with you?

In this presentation, Matthew Hodgson, ZXM Partner Agile & Lean Enterprise Transformation, presented a recent case study involving a government agency, 30 projects, and its need to address its project management maturity. He described how, in only four months, a focus on old school PRINCE2 process and products, combined with modern Lean principles of value, radically changed the way IT viewed its projects, engaged with business, and rapidly accelerated its project management capability. Specifically, Matthew articulated the critical role of Kanban in visualising the value chain of products for projects, programs and the portfolio and how it radically increased transparency and empowered executives to remove project bottlenecks and wasted resources. Overall, he assessed how a focus on mentoring project management capability through the PMO produced an equal need to address delivery issues and the choice to move to combining PRINCE2 with Scrum to drive the agency’s P3M3 assessment toward a 5 – a culture of continuous improvement.

You can view this presentation on the Prezi site at: http://prezi.com/qsmxdusw3gg0/the-lean-agile-pmo/


The Lion, the Mouse and the Thorn of Usability Testing

Presentation at Agile 2013, Nashville USA.

Focusing on User Tasks to Deliver a Better Customer Experience

On one of my recent projects, we were asked to deliver a new Information Architecture for a government website that reflected the depth and breath of its programs. A key challenge for this project was deciding on how to deliver to their customers, information on the broad range of programs that they offered, in a way that was findable and met their customer’s needs.

Our approach was to investigate the information needs of stakeholders and end users of the departmental website and based on this research, develop a new information architecture for the site. Our aim was to deliver a modern effective, user-centered approach to the information architecture  (IA) that focused on the user experience and embedding value into the website’s content and IA.

We focused on user tasks and triggers as we found how the department was structured internally was less relevant to a customer who is seeking information on a specific topic, to do a specific task at a specific time.

user needs as tehy relate to triggers and tasks

Delivering an outstanding customer experience in government is difficult because everyday customers are also doing business with commercial companies like Amazon and Virgin Australia who excel in customer service and those customer experiences drive high expectations for interacting with any organisation, let alone government agencies.

Customer experience (CX) is based on the perception a customer will have when they interact with the agency or any product and service within the organisation. Each time they interact with a website and use any other channel (including digital social media channels), the perception of and trust they have in that agency is impacted.

Task Driven Personas

We conducted stakeholder workshops to identify the numbers and types of users and focused on their needs, rather than what the business areas felt was important to publish. As we know, users come to a website with a specific task in mind. If it isn’t easy to find or if the task can’t be quickly completed, they’ll leave.

The outcomes of the workshops were analysed to provide insights into the key stakeholders and groups who visited the site and we documented Personas’s common tasks and triggers that led to those tasks.

Task Driven Personas

Analysis of Website Data

A content analysis was undertaken on website statistics for the past 12-24 months and together with the information we had gathered in the workshops, we determined what users were looking for when they came to the site. This helped us to identify the users’  top tasks.  

Once we identified a top task, we didn’t just focus on one piece of information, or one web page, at a time. Instead, we thought about how that piece of information fitted into the task people are trying to complete and used that to also inform the site structure and the wireframes.

Homepage Wireframe

Key Steps to Delivering a Better Customer Experience

In summary, here are some of the key steps to delivering a a better customer experience in government:

  • Determine who your most important customers are and the primary tasks they want to accomplish.  These top tasks should be based on quantitative and qualitative web analytics data.
  • Understand what events trigger their search
  • Identify their primary pain points
  • Know what content areas are of high value to users
  • Define clearly what you want the customer experience to be (do an experience vision)
  • XConduct usability testing to measure if customers are now better able to complete their tasks.

Beyond the new new product development game

Keynote presentation at Product Camp Sydney, 2013

Applying a Psychology Based Model to Improve Business Processes

Often, when we find out that we don’t know something that may be important to know, it motivates us to find out more in order to master the skill. When I find out that I don’t know something that is regarded to be important, I’m motivated to learn more about it. However, if we “don’t know what we  don’t know”, then we are blissfully unaware of our ignorance and there’s little we can do about it.

I recently worked with a team where the Manager had seen Scrum used successfully on another project and wanted to see if it could help improve processes within his team. Using Scrum and a psychology based learning model of competency, within three months we were able to take the team from Unconscious Incompetence to Unconscious Competence and provide them with increased efficiencies and a simplified business process to deliver both their Business as usual (BAU) work as well as project initiatives such as the introduction of RecordPoint as the EDRMS, MS Sharepoint integration, MS Biztalk and MS Dynamics.

In psychology, the four stages of competence, or the “conscious competence” learning model, relates to the psychological states involved in the process of progressing from incompetence to competence in a skill. It suggests that individuals are initially unaware of how little they know, or unconscious of their incompetence. As they recognise their incompetence, they consciously acquire a skill, then consciously they use that skill and eventually, the skill can be done without consciously being thought through. At this point the individual is said to have unconscious competence.

The four stages of the Conscious Competence Model are:

  • Unconscious incompetence — This is the first step to gaining knowledge and recognising you have a need. You don’t know that you don’t know how to do something and therefore do not  understand or know how to do something or that there is a deficit. They could deny the usefulness of the skill however, they must recognize their own incompetence, and the value of the new skill, before moving on to the next stage. The length of time an individual spends in this stage depends on the strength of the stimulus to learn.
  • Conscious incompetence — You know that you don’t know and it bothers you so you start to build up your expertise in that area.  Though the individual does not understand or know how to do something, he or she does recognize the deficit, as well as the value of a new skill in addressing the deficit. The making of mistakes can be integral to the learning process at this stage.
  • Conscious competence — You know that you know how to do something and it takes effort. The individual understands or knows how to do something. However, demonstrating the skill or knowledge requires concentration. It may be broken down into steps, and there is heavy conscious involvement in executing the new skill.
  • Unconscious competence — You know how to do something and it is second nature – you rock at it. The individual has had so much practice with a skill that it has become “second nature” and can be performed easily. As a result, the skill can be performed while executing another task. The individual may be able to teach it to others, depending upon how and when it was learnt.


Source: http://www.mindofallan.com/2011/02/learning-process-how-we-master-any-skill/

High Performing Teams – The Fifth Stage – The model is expanded by some users to include a fifth stage, which is not part of the original model from Gordon Training International and the exact composition of this stage varies between authors. Some refer to reflective ability, or “conscious competence of unconscious competence”, as being the fifth stage, while others use the fifth stage to indicate complacency. For me, the fifth stage is what differentiates high performing teams from other teams. Rather than becoming complacent, the individuals within the team  adopt a life long learning approach to continuous improvement of competency, and these high performers will not stand still but instead will continue to push boundaries in their thirst for knowledge. 


This model has been particularly helpful in getting agile teams to understand where they are at in their knowledge and skill level and what they need to learn to improve performance and achieve process improvement.


Get every new post delivered to your Inbox.

Join 188 other followers