What are the key considerations when choosing to adopt agile methods in a government context?
This whitepaper by Zen Ex Machina Partner, Matthew Hodgson, 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, Matthew 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:
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.
So you’ve just finished usabilty testing in your Sprint and have a pile of changes for the Scrum Team to implement. Some are changes to Definition of Done for existing User Stories, some though, are wholy new User Stories. For the most part, the Business Owner and Product Owner agree that the application does require work now to encourage that people to drop their old behaviours and use the new system, but the estimations the Team have done suggest that it’s about two whole Sprints worth of work. How do you break down this work into smaller, bite-sized User Stories?
This was one problem I faced not too long ago. After doing some usability testing, there was a significant body of work to do. While many of the estimates for the work were very high, the effort (to use Mike Cohn’s analogy) was more like licking 1,000 stamps than brain surgery. So here are the top patterns I used with the Team to break down the work.
1. Text changes first
Labels, nonclementure, and formatting were the easiest change to make, particularly where visual flow and visual contrast were concerned, so where stories required these surface UI changes, these were done first.
2. By most frequently used
In many instances, the usablity recommendations encompassed many, many, many pages. One of the easiest methods we employed to break down work estimates was to list the pages affected and then order the pages by their frequency of use. Pages were then grouped into three categories — top 20%, next 20%, bottom, 60%. The group that had the highest traffic received attention first. For the most part, those pages that fell into the bottom 60% were not changed.
3. By highest value
While there was agreement that addressing the usability issues on most frequently used pages was of high value, the Team also recognised that some pages were not used often, but represented a very significant step in a process that was critical to get right. The likelihood of human error in these pages from a risk perspective was also taken into consideration. These high-value pages were identified by business and ranked in much the same way that they helped the Product Owner in the past rank functionality. In many cases, these were pages that were of high cognitive complexity — many fields and a lot of text to be entered. Again, these were grouped into 20%/20%/60% split and the top 20 ranked higher in the Product Backlog to address than the remaining 20/60.
4. By supported area
One of the areas of concern by the Team was in making changes to areas within the software solution – Microsoft Dynamics CRM — that were not supported by Microsoft. If the Team made a change, and the software was upgraded and ran into problems, the Team doing the maintenance would be left on their own. So, we made a choice to split some of the User Stories by “supported area”, with changes required to supported areas, e.g. the body of a page, ranked higher than those that were not supported, e.g. the left-hand side navigation menu.
5. Illogical to the logical
Where workflow was involved, the steps were broken and ranked to identify the pages that represented the most confusing interaction design to the least confusing. The time taken on pages during the usability testing was one factor that contributed toward it being identified as ‘more confusing’ as did the visual complexity of the page.
6. By most valued user
One of my favourite patterns is to break up stories so they deliver the most value possible to one user before delivering value to another one. This is a pattern we also adopted for breaking down large usability stories through ranking the user types, and then identifying the pages they used within the application. These pages were identified for usability improvements prior to other pages used by other users.
I’ve been Coaching Scrum for government agencies in Canberra (Australia) for quite a few years now. It’s an ideal framework for managing projects and programs of work because Ministers can change their minds about policy or suddenly announce new ones and it enables systems that support the machinery of government need to adapt to new technologies, new stakeholder needs. I’m finding, though, that while many agencies have attempted Scrum in the past, unfortunately many have had mixed success and sometimes failure.
What does it take, then, to produce results when using Scrum in a highly regulated, hierarchical, and often risk-averse culture like a government organisation? Here’s my top 5 tips:
1. Adopt all of Scrum, not just the bits you like
Scrum is an end-to-end process. Each and every key meeting and activities has been refined by its creators over the last decade. They work best when implemented as a whole methodology. When only parts are used, you are unlikely to get any real benefits/realisation. Since Scrum is based on a Deming Cycle, its key meetings help to identify issues and help the project and team to improve. If key meetings aren’t working well, rather than discard them, identify the key meetings that aren’t [apparently] of value, identify what’s the root cause, and act upon it to improve the Scrum’s efficiency.
2. Continuous planning is needed, not just upfront
The ANAO  suggest that estimates of project costs and timeframes at early stages of project planning are likely to be inherently uncertain. Scrum helps managers, Product Owners and the team undertake detailed planning on a continuous basis that builds on earlier planning to remove ambiguity and produce clarity around tasks, deliverables and outcomes. This confirms project requirements are sufficient to guide a project to deliver planned outcomes that are of value to the project now and avoids, therefore, wasted planning effort and issues associated with the risk of unrealised expectations amongst stakeholders. To be successful, though, adequate time has to be made for planning at the beginning of the Sprint, as well as mid-way through to review with the whole Backlog with the team prior to the commencement of the next Sprint. Ultimately, planning for projects is the same as in hiking or even warfare: when the terrain differs from the map, believe in the terrain.
3. Governance is key to enabling removal of impediments
There’s only so much the team can influence. Good governance ensures that those on a project board or committee have been selected because, should the project hit a bump in delivery, these individuals can act to help move the project along. This can encompass anything from procurement of servers for integration testing through to influencing other teams to assisting in providing requirements in a timely way. One important factor to consider is how involved the project’s owner is in contributing to the order of items in the Product Backlog and informing the Product Owner of his needs and priorities. When the project owner is informed, they’re empowered to act on behalf of the project so that it achieves its goals and delivers on its return on investment (ROI).
4. The Scrum process produces transparency and accountability, not reporting
Most projects are used to creating reports of current activities to increase transparency about what is going on in the project — current goals, milestones and risks. Scrum’s process itself produces transparency with its key meetings, like the daily standup, to its use visualisation techniques such as a Kanban Board. One of the keys to successful use of Scrum is to recognise that simple artefacts that come out of the process can be immediately used for reporting rather than adding the requirement to produce additional reporting artefacts such as project schedules. Even if the project operates in a PRINCE2 environment, there are many equivalences that can be drawn between PRINCE2 reporting artefacts and key elements that are produced by Scrum. I find that the synergies between the Scrum and reporting work best when both cycles are 4-weeks in length — so when a Sprint Goal has been defined, the previous Sprint’s milestones are reported along with the next Sprint’s goals.
5. Your team doesn’t know what they don’t know — its why a coach matters
It’s very difficult for most teams to be accurate in their introspection and identify what it is truly doing wrong and what factors will contribute to improvement and success. Scrum coaching goes beyond training. It’s designed to take the guessing game out of why, for example, a team might fail to achieve their Sprint Goal, or why certain Waterfall-style behaviours might actually impede the success of a Sprint. Overall, a coach helps teams to learn, improve, become more efficient, and helps to reduce the risks associated with the team’s behaviour impacting adversely its ability to deliver. One key factor in choosing a Scrum Coach, however, is finding one that understands the needs, accountability, and processes of government, and can frame Scrum in a way that aligns with this vital perspective.
It takes both a sound knowledge of Scrum and an applied understanding of how to use it in order to reap the benefits that this agile methodology has to offer. These 5 tips only represent a fraction of what’s required for successful adoption. For more information, request a copy of our whitepaper — Agile Adoption in Government.
- – -
1. Australian National Audit Office (2010) Better Practice Guide. Planning and Approval – an Executive Perspective.