A Federal Government Shared Service Success Story: Buyandsell.gc.ca
Phoenix, the federal government’s pay modernization initiative, aptly illustrates the federal government’s challenges with successfully deploying shared services. Phoenix, Shared Travel Services, and the Government of Canada Marketplace demonstrate that traditional waterfall project management coupled with an excessive emphasis on specifications can exacerbate risk and produce less-than-ideal results.
On schedule and on budget, Buyandsell.gc.ca began hosting the Government Electronic Tendering Services on June 1 2013. The shared services offered on Buyandsell.gc.ca help more than 80,000 private sector suppliers and buyers representing more than 90 federal departments and agencies to focus on doing business, instead of figuring out how to do business. Buyandsell.gc.ca hosts more than 1 million page views per month.
Buyandsell.gc.ca constitutes a series of successful transformation projects. These projects are a possible template for transforming government services to citizens. However, in the Buyandsell.gc.ca case, leading stakeholders never considered transformation their goal and at no time was their work managed as a transformation project.
Buyandsell.gc.ca is the result of an iterative process of discovery. The team asked open questions and was open to all possible answers. They eschewed traditional requirements definition and delivered incremental improvements guided by a strategic intent: to improve the user experience of tender management. By allowing tender creators and consumers to validate the improvements via real systems, and by accepting a long-term process of continued short-term iteration, a transformed system was made operational. That system is built upon loosely coupled foundation (platform) components that can be added to in order to deliver additional services without impacting Buyandsell.gc.ca itself.
While this approach remains unfamiliar to many in the federal government, it is based upon Agile methodologies widely used in the private sector. These techniques present a lower risk than the waterfall project management approach (the National Project Management System) traditionally use for federal government projects.
This presentation summarizes key Lessons Learned in the conception, design, implementation, and delivery of Buyandsell.gc.ca. It references best Agile practices in relation to its achievements.
Outline/structure of the Session
Our team compiles lessons learned during our major building phases. We operate in an AGILE-ish environment. We use bi-weekly iterations driven by what begin as broadly defined business outcomes that are refined into executable business requirements.
Each lesson is accompanied both by the mistakes we made and things we improved. Broadly the lessons were:
Lesson 1 - Discover needs and deliver solutions in manageable chunks
Do not allow a long-horizon project management methodology to override practical, business-driven outcomes with early, demonstrable results. If you assume you know more about the problem than you really do, you risk committing to a solution path too early.
Lesson 2 - Manage community engagement with prioritized, doable roadmaps
Stakeholder expectations must be managed throughout the project.
Successful projects deliver a working service to its stakeholders. It must do what is expected and stakeholders must be willing to use it. Unsuccessful projects miss one or both of these conditions.
Lesson 3 - Have long-term strategic goals, but short-term working pilots
Traditional project management systems (often modelled on construction projects) tend to deliver usable components only at the very end of a long development cycle. To have meaningful engagement, stakeholders must be able to judge tangible results on a regular basis throughout development.
Lesson 4 - Deliver modular, incremental improvements
Do not attempt to deliver all of the solutions to all of the problems at the end of an extended development effort. Rather, provide usable solutions in an incremental fashion, such that stopping at any point still leaves you with measurable gains and workable systems.
Lesson 5 - Have small, skilled teams focus on separate and distinct concerns
Take advantage of modular delivery to allow separation of concerns. By managing each module separately, you can use tools, products, and business knowledge specific to the module to its greatest advantage.
Lesson 6 - Don’t integrate, interoperate
Integration, whether between modules or different systems, requires too much knowledge of the other component’s internals. Interoperation through a clean external interface allows modules to remain independent and autonomous.
Lesson 7 - Take advantage of open technologies
Open technologies provide many significant advantages: they have no external platform dependencies, they are easy to procure, they are broadly supported by large user communities, and they do not create large sunk costs.
Lesson 8 - Don’t ignore things that work
When replacing or improving a service, there is a tendency to start with a “clean slate” without regard to the utility or functionality of existing systems and procedures.
Lesson 9 - Use a dedicated demo environment and keep it real
Avoid two common pitfalls: 1) Using your development environment as a demo environment; 2) Taking shortcuts to make demos work. Make the demos even more useful by using the collected feedback for the next demos.
Lesson 10 - Develop with operations in mind
At some point, discovery and development will give way to operations. Developers should strive to make the transition as frictionless as possible.
The session will conclude with a set of common themes that we identified based on the above lessons.
Participants will be able to:
- Leave with a map of the mistakes our team made along the way as we figured out how to build Buyandsell.gc.ca
- Understand how the Buyandsell.gc.ca projects were framed within the broader context of the National Project Management System
- Suggest areas where Agile methodologies could be applied to solve known federal government challenges
Enthusiasts, Developers, Advisers, Executives
schedule Submitted 10 months ago
People who liked this proposal, also liked:
From dysfunction to cross-function in 8,593 easy steps: Team building at the CBC
When it comes to scaling Agile, there is no one size fits all solution. Frameworks like Scrum and XP prescribe roles, events, artifacts, and rules that make it very clear how interaction should take place within a team. When we begin to add more teams to the mix, communication between teams becomes more complex. This complexity threatens to reduce our transparency and damage our culture. How can we share information, build our culture and work together, all while keeping with Agile values?
During this session Sam Lightowler and Jade Stephen will take an in depth look at the successes and failures of CBC Digital Operations when it comes to cross-team collaboration and information sharing. We will discuss what meetings and techniques have helped us build a one-team-one-product mindset, a sense of community, and a culture of Collaboration, Learning and Improvement. We will also discuss what we have tried in the past and how learning from those experiments helped us evolve into the agile-friendly and unified team that we are today.
How Agile is leading the Digital Government Revolution
Governments have typically been slow in adopting Agile principles. In 2014, the launch of the healthcare.gov product was generally considered a failure. At the same time, the Organisation for Economic Co-operation and Development (OECD) published a report recommending governments to implement Digital Government Strategies to bring them closer to citizens and businesses. Since then, the flurry of activities around Digital Government has accelerated and led to some very interesting organizations and initiatives such as:
- UK's Digital Government Services
- The launch of the US Digital Services Playbook
- The creation and growth of 18F
- The creation of the Australian Digital Transformation Office
- E-Estonia's rise to the top of the Digital Government charts
- The creation of the Ontario Digital Government Action Plan and the recruitment of a Chief Digital Officer
Agile methodologies - combined with user-centred design principles - are often at the heart of these Digital Government initiatives. The timing has never been better to help governments accelerate the implementation of Agile principles, user-centred design and outcomes management to deliver better value quicker to citizens.
Through this session, attendees will:
- Better understand governmental constraints and why governments have typically been slow adopters of Agile principles
- Learn about recent worldwide Digital Government trends and initiatives
- Review approaches as to how agile methodologies can be applied in the context of existing Government of Canada IT project management frameworks
- Discuss examples of Government Agile projects and products that have delivered better value quicker to citizens
Scale, the most hyped term today, but really, how do you scale successfully?Patricia Kong
schedule 1 year agoSold Out!
Scrum is everywhere, with over 90% of agile teams using it. But for many organizations wanting to scale agile, one team using Scrum is not enough. Scrum is not enough. The Nexus Framework, created by Ken Schwaber the co-creator of Scrum, provides an exoskeleton to Scrum, allowing multiple teams to work together to produce an integrated increment regularly. It addresses the key challenges of scaling agile development by adding new yet minimal events, artifacts and roles to the Scrum framework.
In this talk, we introduce the Nexus Framework and how it, like Scrum, promotes bottom-up thinking with top down support in order to discover and emerge what works best for your organization. We will use case studies as examples to describe Nexus in detail showing how it works, how it is working, and what its strengths and weaknesses are. The audience will be taken through Nexus, its new events and the key role of the Nexus Integration Team.
Outcomes-Focused Agility - Story Mapping for achieving Strategic Intent
Florence Nightingale is considered the founder of modern nursing. Put in charge of nursing British and allied soldiers in Turkey during the Crimean War, Nightingale was the first person to define planned consequences from activity as the basis for action when she introduced evidence-based outcome indicators to nursing and healthcare.
Nightingale’s approach was later applied to outcomes-based education and in programme management with the introduction of ‘logic models’. Fundamentally, it is a quality management approach focused on helping us get the desired results from our interventions and activities. Nightingale was arguably the first person who figured out that you need to start with framing the result you want to achieve (the why) to determine what you should do, how you should do it, when you should it, and where you should do it - all the while using an inspect and adapt mindset to interpret actual results against expected ones to determine the next course of action to be taken, including re-framing the expected results based on what we have learned so far.
In this interactive session the two Larry's (Cooper and Sullivan) will be your guides as you learn how to identify the goals and objectives (the why) for a real world scenario, how to use a simple canvas and mapping technique to figure out what needs to be done and in what order, and how to adapt what gets done next based on what we have learned so far. The mapping technique is similar to story mapping except that it provides a deeper understanding of the true nature of most projects in enterprise settings - this technique helps us story-map our strategic intent.
It helps us to more clearly identify and solve the minimum viable problem.
For Product Owners it will help them gain better insights into how value gets defined at an enterprise level and provides a line of sight from strategic goals and objectives down to actual products too be built. For leaders it helps them understand that most projects are often really multiple ones that need to be sequenced and that it is the work that is often not identified and hence not done that sinks most large efforts.
These techniques provide clarity and allow us to deal with uncertainty when dealing with complex problems and messes while maintaining agility throughout.
Scaling Agile - Adventures with SAFeAnnette Lee
schedule 11 months agoSold Out!
If you have multiple scrum teams working together to deliver business value, you'll be thinking of moving to Scaled Agile. In our company we have a number of different product lines all running with multiple scrum teams. We needed a way to roll up all of that information and track the progress of our releases. We also needed to do roadmap planning. In this presentation, I'll go over our learning curve in Scaled Agile and our experience with SAFe (Scaled Agile Framework).
A case study in scaled and self-organized ScrumSean McFee
schedule 1 year agoSold Out!
A green fields development project presented a good opportunity to experiment with an agile way of work involving increased team self-organization. Initially this involved confronting a traditional command-and-control approach with something based more closely on the Scrum Guide, while surmounting a number of impediments that are common to many organizations. Over time, as the project grew, scaling problems were discovered and had to be dealt with, ranging from simple things like meetings to more complex issues like team composition.
Servant Leadership, are women the better fit?Patricia Kong
schedule 1 year agoSold Out!
Do women make better Scrum Masters, because they’re more nurturing? Do women have to be aggressive in order to be effective leaders? Why aren’t women good risk takers? Let’s explore these topics, other stereotypes, and different myths and facts that surround the female role in agile and technology. Patricia Kong from Scrum.org and Jill Graves from the Canadian Revenue Agency will share their experiences and facilitate this discussion to explore why women are stalled in leadership roles and in the technology industry, and if Agile can help.