The recognised standards on Agile delivery across government can be found on the Service manual. New starters are requested to familiarise themselves with this. It covers:

Agile delivery

How to work in an agile way: principles, tools and governance.

Understanding agile project management

Introductions, methods, core features.

Working with agile methods,

Workspaces, tools and techniques, user stories, planning.

Governing agile services

Principles, measuring progress, spending money.

Phases of an agile project

Discovery, alpha, beta, live and retirement.

Read more

Teams at Homes England are recommended to use an agile approach to project management to build and run government digital services. Agile methods encourage teams to build quickly, test what they’ve built and iterate their work based on regular feedback.

For an initial understanding of the basics of what Agile is, the Agile Manifesto can be found here: https://agilemanifesto.org/​ Following on from that, The Twelve Principles of the Agile Manifesto can be found here: https://agilemanifesto.org/principles.html

Scrum

Scrum is the most commonly used agile method. It allows a highly structured model with clearly defined roles and responsibilities. Scrum is a framework for delivery management that concentrates on teamwork, accountability and iterative progress toward a well-defined goal or Minimum Viable Product (MVP). The framework begins with a simple premise: Start with what can be seen or known. After that, track the progress and tweak as necessary

Learn more about the features of Scrum in the Scrum Guide, written by the developers of Scrum, Ken Schwaber and Jeff Sutherland.

Kanban

Kanban as a development method was inspired by production systems that focus on reducing waste and improving quality, like those created by Toyota. Kanban is a way of visualising and improving your current working practices so that work flows through a system quickly.

A fast and smooth flow of work means you can:

• Deliver value quickly and predictably
• Get early feedback to find out whether your product or service is meeting user needs

Read a brief introduction to Kanban.

Read more about Lean Principles we have adopted at Homes England.

All development teams responsible for software development in an agile environment should follow the 7 +/- 2 rule laid down within agile ways of working, with a focus on the following roles​:

• 1 x Delivery Manager​ - Responsible for facilitating the team, obtaining resources for it, and protecting it from problems, removing blockers, ensuring the team has what it needs to do its job, coaching the team when necessary
• 1 x Product Manager​ - responsible for the vision, priority order of the backlog and negotiating with the team what order they want to build in, represents the end user and all of their needs
• 1 x Business Analyst
• UCD (User Researcher, Content Designer, Service Designer, Interaction Designer) Developer(s), QA Test

​​​​​​​The skills a team will need may change throughout the lifecycle of your service but this is a standard team shape to deliver digital change. Teams may also need SME’s like Architects, Data and Infrastructure engineer, who will support the team where needed.

​​​​​​​All development teams are to act as self-organising, autonomous teams that develop strong relationships working collaboratively with the wider business units ​.

​​​​​​​Some larger services will have a Service Owner who is accountable for the quality of a service. They must have the decision-making authority to make changes to a service and drive the vision. Service Owners adopt a portfolio view, managing end-to-end services which often include multiple products and channels.

​​​​​​​They have overall responsibility for developing, operating and continually improving a service. Product Managers work with Service Owners to ensure Service Teams are delivering changes that move towards the vision of the Service Owner.

Benefits

• Team of digital specialists empowered to build and support services quickly and iteratively. Keeping the team together retains knowledge, improves ways of working, collaboration and supports planning.
• People will get familiar with roles, responsibilities, build relationships with stakeholders, increase understanding of service standard and assessments
• Local prioritisation and decision making. The whole team work together to design, build and iterate a service based on the user needs of the people your service is aimed at.
• All projects are likely to fall in to category of or be requested by specific business/tech areas. Bi-directional familiarity will make prioritisation, managing WIP, escalation, reporting easier
• Teams will have the breathing room to work with service owners to tackle legacy/tech debt whilst building clear and consistent wikis on services
• Encourages consistency of delivery/data/infra/soft/arch standards, ways of working and collaboration across teams through CoPs
• Makes life easier as the we shift focus on to one area that requires less domain knowledge, fewer services to deal with, less context switching

Project Kick Off

This content is coming soon!

Project Closure

This content is coming soon!

Backlog

Backlog refinement overall is a team effort, led and facilitated by the aforementioned roles, it is a regular, ongoing process, defined by the agile ceremonies that Homes England teams use in Scrum (Sprint Planning, Three Amigos, Refinement) or Kanban​

Go through each ticket in flight and get updates on it - close down no longer required tickets (steer from the Product Manager) to ensure that the backlog is as up to date as possible​

Anyone can put a new item in the backlog but they MUST inform the PM in advance who will then in turn prioritise the item - without that communication and letting everyone add stuff to the Product Backlog often results in reduced transparency, lack of clarity, a wrong ordering and loss of manageability.​

Ensure by chasing the PM that the backlog is still in relevant priority order. Priorities can be decided on ROI to the organisation, benefits to the customer/end user, technical common sense (build one service/screen) before another - process flows/maps can be a useful visual aid to map the user journeys/data flows and to then write/prioritise user stories against them (that helps decide what order you might consider doing work items in)​

Stories near to or at the top of the backlog should meet your team’s Definition of Ready ​

A useful acronym to consider when managing your backlog is DEEP:

• Detailed Appropriately. User stories on the product backlog that will be done soon need to be sufficiently well understood that they can be completed in the coming sprint. Stories that will not be developed for a while should be described with less detail.
• Estimated. The product backlog is more than a list of all work to be done; it is also a useful planning tool. Because items further down the backlog are not as well understood (yet), the estimates associated with them will be less precise than estimates given items at the top.​
• Emergent. A product backlog is not static. It will change over time. As more is learned, user stories on the product backlog will be added, removed, or reprioritised.​
• Prioritised. The product backlog should be sorted with the most valuable items at the top and the least valuable at the bottom. By always working in priority order, the team is able to maximise the value of the product or system being developed.​

​

Our backlogs are a statement of intent. They are kept in priority order from 1 at the top to N down the bottom (on a daily, weekly sprintly basis). They can be used to visualise the order in which we want to release our code/services. Start with any deadline dates and reverse engineer to your start date – then start to map out your sprints

Roadmap

A roadmap is a plan that shows how a product or service is likely to develop to achieve a particular goal.

For service teams this goal will be the vision developed with the Service Owner. Each service or product should have a roadmap maintained by the product manager.

A good roadmap:

• Makes it clear what you’re trying to achieve (Vision)
• Sets out the steps your product will take to get there (iterations)
• Helps users, development teams and stakeholders understand the outcomes they are likely to see
• Helps the wider team understand how what they’re working on relates to future priorities
• Supports conversations to prioritise based on value
• Is not a promise to deliver; they capture intent and allow for change and regular review as we learn more
• Helps readers understand what is not being done e.g. if the product delivered in beta will only be usable by 20% of all applications the roadmap is a good place to reflect this outcome

Discovery

Before committing to building something, we need to understand what the user needs are and if a new thing is needed. This is Discovery.​

Discovery de-risks the future. It allows us to understand the scope of a problem and the best way to proceed in response.​

Activities in discovery include:​

• User research​
• Analysis of business needs​
• Market research​
• Journey mapping
• Cost analysis

We are not building software in discovery. The outputs of a discovery include:​

• Recommendations on the best way to proceed​
• A prioritised list of user needs that future development work can be planned against​
• Findings about current processes or the existing service​
• Estimated scale and costs for developing a new service​

Alpha

After committing to building a new service, we need to understand how it will work for users and how it will integrate with existing processes and systems.

Alpha results in a better and more focused service. It allows us to understand how users will interact with the service and what is technically possible.​

Activities in alpha include:​

• Building test designs or concepts
• User testing​
• Service design​
• Technical audit and exploration of existing and legacy systems​

We are usually not building software in alpha, even though it might look like it. The outputs of an alpha will include:​

• Designs that have been tested and iterated with users​
• A roadmap and plan for a beta phase
• Metrics to measure performance​
• Research findings in the form of user stories and journey maps​

Beta

With a clear scope, user needs, and technical approach in place, we are ready to build a working version of the service. This is beta.​

Beta results in software that can handle real transactions and is ready to work at scale. It allows us to develop better services that meet user needs.​

Activities in beta include:​

• Developing working software​
• Testing and iterating
• Getting the service accredited​
• Measuring performance​
• Developing and testing a security approach​

We are building software and technical infrastructure in beta. The outputs of a beta will include:​

• Working software that is being used for real transactions​
• Technical infrastructure to support the new service​
• Metrics about the performance of the service​
• A backlog of development tasks for ongoing iterations​
• An approach for security​

Live

Once a service is being used for real transactions, continuous improvements can be made based on feedback, research and data. This is Live.​

An active digital service is never ‘done’. The live phase allows us to respond to change and new research findings in order to keep iterating the service.​

Activities in live include:​

• Iterating and improving the service​
• Measuring performance​
• User support​
• Testing the service for security​

We are continuously improving and supporting working software. The outputs of live will include:​

• Iterations and improvements to the service​
• Metrics on performance​
• A backlog of development tasks for ongoing iterations​
• Security tests​​

1. Azure DevOps to manage team backlogs and development, integration and branching strategy.
   
   Please see our dedicated page for in-depth guidance on how to access, configure and use Azure DevOps
2. Microsoft Teams for productivity and communication
3. Microsoft Project Online for reporting and resourcing

Line managers are responsible to request access to Office 365 for new starters.

At Homes England our portfolio consists of:

• A single portfolio with defined governance to establish a clear route to delivery
• Heads of professions supporting portfolio prioritisation, governance and resourcing
• Stable multidisciplinary teams working collaboratively with business stakeholders
• Clearly defined WIP limits to surface capacity of operational and delivery teams

The Project Management Office (PMO) offers a wide range of services to stakeholders across Digital and the wider organisation in order to support and improve project delivery and provide greater assurance and benefit realisation.

Read more

BAU or Project

We empower teams to iteratively identify, prioritise and deliver value. However, there may be situations when a proposed project requires additional governance, specialist skills or funding outside the scope of the team.

We've written guidance to support leadership and teams determine if a piece of work is BAU or meets the threshold to go through the portfolio front door and governance process.

Read more

This content is coming soon!

This content is coming soon!

A regular forum where best practice is shared between amongst peers. At the moment the following communities of practice exist in Homes England.

• Delivery
• Product
• Business Analysis
• UCD
• Data
• Heads of Profession Community

Please use the links above to view the terms of reference for each community.

Please contact the profession lead to join the community. You do not have to be an existing member of that profession to join a community and all are welcome.

Week Notes

What are weeknotes?​

We use weeknotes to inform the people we’re working with about our progress, issues we’re dealing with, and what we’re planning to do. They can be a really useful way to update people you deal with directly, but they can also be shared more widely with people who are less directly involved in a day to day basis.​

What makes a good weeknote?​

A good weeknote:​

• Sounds like it was written by a human. Ask yourself whether it would be something you’d be happy to receive and read. You don’t need to make it too formal.​
• Is honest about progress as well as issues. This is a good way to flag things that need to get dealt with on a project.​
• Gives a sense of what the team is delivering as whole. Don’t just write bullets covering what every individual on the team did that week.​
• Brings the project to life. Do you have any images you can use to illustrate what you’ve been doing?​
• Is frequent and regular. This is a good way to build trust with the wider team.​

We send out weeknotes to update you on progress. Weeknotes highlight things we’re worried about, acknowledge achievements and show progress, and layout what we plan to do next. Along with our show and tells, this is the main way you will find out about the project so please read.​

Good Things​

What are the main highlights this week? Have you hit any milestones, or overcome any significant blockers? What decisions have been made? Do you have any images to show progress? (e.g. a photo from a workshop, or a screenshot of something that’s been built?)​

Learned things​

Have the team learned anything from a retro? Did anything happen that you didn’t expect? Have the team made any changes to how the team operates? Have the team uncovered anything new from user research? Does anyone from the team have any personal reflections that they’d like to share?​

Difficulties​

What challenges or issues does the wider project team need to be aware of? How are you dealing with them? What help do you need - either from within the project team or elsewhere?​

Achievements​

Are there any team achievements that need recognising? Are there any individuals you want to recognise? (they don’t need to be inside the core project team - they could be someone from a different department who helped you out this week).​

What’s next​

What are you planning to deliver in the next sprint? When is the next show and tell? What key meetings are coming up?​

Delivery Managers release a combined weekly week note that is distributed across Digital

Show & Tells

This content is coming soon!

This content is coming soon!

The Team Health Check is a self-evaluation tool, a workshop format, to help you improve and become stronger as a team. The goal of the workshop is to increase self-awareness, trigger discussion on how you can improve as a team and how you can be even more successful at collaboratively deliver value to your users and stakeholders.

Read more

This content is coming soon!

This content is coming soon!

For more information on our Information Security policies, please see links below.

• Engineering Secure Systems
• Secure Development Principles

Read about our Software as a Service (SaaS) Procurement process.

Pluralsight

We have curated learning paths for Senior, Mid and Associate Delivery Managers with specific courses that are available for all permanent members on Pluralsight.

Recorded Coaching Sessions

User Centred Design (UCD)

Overview of Kanban

Overview of Scrum

Digital Accessibility

Backlog Management

Making Content Accessible

Other Resources (Books, Courses, Articles, Videos)

Any requests for formal training should be made to your line manager. If you would like the community to present a topic please contact the Delivery Community.