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:
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.
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).
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 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.
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!
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/
Presentation at Agile 2013, Nashville USA.
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.
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.
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.
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.
Keynote presentation at Product Camp Sydney, 2013
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.
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.
Regardless of whether you’re running an agile or waterfall project, effective project governance and stakeholder management underpins project success and results in efficient and timely decision making.
Recently I was working on a project where there were times when decision making was stalled, while the Team navigated through a complex governance matrix, designed by the PMO, to get “everyone’s fingerprints all over it”. The result at the project level were delays — the Team were simplly not empowered to move forward until the governance process had completed its cycle, which included:
- 6-8 weeks to get stakeholder review.
- Waiting until Senior Executive and Project Board meetings aligned to facilitate the review.
- Evaluation and approval of products by all corporate stakeholder groups.
Given our Sprints were four weeks long, there was a very real disconnect. We were falling down on the basic principles of effective governance.
I found Ross Garland’s Project Governance: A practical guide to effective project decision making, a useful staring point to develop a project governance framework that would clearly articulate the accountabilities and responsibilities for the project (RACI-VS model) , was focused on outcomes and allowed stakeholder feedback to be sought when expertise was required.
Four principles of effective project governance:
- Ensure a single point of accountability for the success of the project. This ensures clarity of leadership and timeliness of decision making. In Scrum it is the Product Owner who is empowered to make project decisions. This accountability is not shared by a committee, as the product owner is the single point of accountability. Without this clear authority, the validity of decisions could be questioned if this authority has not been established. In my project’s case, this authority was unclear and therefore consensus and approval was sought from a range of stakeholders and many levels of committees. The result was delay s in decision making and a blowout of timeframes to deliver.
- Ensure the project governance is service delivery focused. Service delivery ownership determines project ownership and this places the business (and customer) at the heart of project delivery rather than the supplier/vendor. In Scrum it is the Product Owner who owns the business case and budget and therefore retains the key project decision making responsibility. By keeping the focus on service delivery and outcomes this will ensure that the Team is producing products in ranked order that are of most value to the business and/or its customers.
- Separate stakeholder management and project decision making. Ensuring separation of stakeholder management and project decision-making activities helps to prevent decision-making forums from becoming clogged with stakeholders all wanting to “put their fingerprints all over” the project . On my project, the PMO justified the exhaustive stakeholder group reviews as a way of mitigating risk that the stakeholders would not be accepting of the final decision if they had not been consulted. Whilst many people may be aware of a project and have input into shaping it, this doesn’t mean that everyone needs to participate in each critical project decision. Stakeholders do need to have the opportunity to raise issues and concerns however these can be done separately in a stakeholder forum rather than in the project decision making forum.
- Separate project and organisational governance. This is the big one for me. Project governance, the process by which project decisions are made and issues resolved, is very different to how decisions are made and issues resolved from an organisational perspective. Separation of project governance and organisational governance structures will reduce the number of project decision layers, since the project decision path will not follow the organisational line of command and control. On my project, the organisation structure was used as the project governance structure which meant that decisions were reviewed and approved at each level of the organisation. Consensus needed to be reached at each level before any decision could be made at the top for the final approval. Navigating this structure was complex and time consuming. Sprint reviews became the trigger to start the approval process rather than giving the sign-off and acceptance of definition of done that the team required in order to move onto the next Sprint. In addition to slowing down the decision making process, we found that the quality of the decision was also impacted as some of the stakeholders involved didn’t have the prerequisite knowledge and understanding of the project and its issues.
Project Governance Framework
The project governance framework below is based on Prince2. Accountability for the project sits with the Product Owner who chairs the Project Board. The decision making path is clear for the Team who are responsible for delivery of the project. The Product Owner ranks products in the backlog and signs-off on the definition of done according to the acceptance criteria. Stakeholders and subject matter experts are briefed and informed as part of the advisory and feedback paths. This structure recognises that the decision making path is via the Project Board.
Implementing an effective project governance framework is challenging and the hardest part is breaking old habits of defaulting to the organisational structure as the project structure.
I have found Scrum within a Prince2 framework to be a very effective in facilitating decision making and applying the key principles of project governance.
This structure allows the Scrum Master and the Team to make the majority of project decisions on a day to day basis and only those decisions such as endorsing the Business Case or approving the project Plan, will need to be made at the Project Board level.