I’m part of DWP Digital’s Get Citizen Income Information team which is tasked with understanding how DWP supplies income data to DWP services.
I’ve blogged previously about our experience during the discovery phase of the agile lifecycle. Now we’re nearing the end of our alpha phase I’d like to share the ways of working we’ve used throughout.
These were decided by the team together in one of our first planning sessions. Introducing new full-time team members and moving to a dedicated workspace (moving from our discovery room) with desks, we wanted to start as we meant to go on. These are the principles we adopted:
-
Have frequent show and tells
Keeping our momentum from discovery we committed to delivering a show and tell every two weeks where all stakeholders were invited. These were to be held in Newcastle for those on site able to join us, paired with an online show and tell where off-site colleagues could join for updates.
-
Do a daily stand-up at 10am
During discovery our daily stand-up for the team to discuss progress and impediments was at 9.45am but for alpha we moved this back 15 minutes. This was the best time to make sure that any external commitments, traffic woes or different working patterns didn’t prevent us from meeting as a team.
-
Collaborate, collaborate, collaborate
We were committed to saying no to isolation! Pairing up with a buddy wherever possible not only increases visibility of the work going on, but it can help other team members to gain skills and insight too. In addition, we also made all team Outlook calendars open. Knowing the whole team’s availability seems like a small thing but it really helped us collaborate more effectively.
-
Build what we need when we need it
Building new features as and when required is really important. It makes sure that time is spent actually building things needed as opposed to busy work. Keeping it lightweight saves time and effort.
-
Work out loud
Our key objective is to serve as many stakeholders as possible while meeting the needs of our users. To help us do this, talking openly about the work we do and promoting the benefits of the service through blog posts is essential. As a team we all create and publish relevant content, it’s not left up to the product owner to report on and promote the efforts of the team.
-
Agree the design together
There is no tyranny within our team, the service’s design is shared and understood by all, with each decision open to challenge. Whilst each individual has skills and specialisms, the service we’re building must be understood by the whole team with design choices held up to scrutiny. At no point can a decision be made with a ‘because I said so’ response.
That said, it’s crucial to keep aligned to the digital standards set by DWP Digital and Government Digital Service to ensure the team works to best practice.
-
Get the whole team involved in user research
As we moved from discovery to alpha we still aimed to put user research at the heart of our development. Putting users at the core of our service and building to meet their needs is core to our aims regardless of development stage.
Because of this we ensured that all members of the team were involved in the user research for the service via workshops, calls and interviews.
-
Build everyone’s capability
As the team grows we expect each other to learn as we go, acquiring new skills and understanding new concepts. For this reason all team members are invited to sit in on sessions in our open working environment. Learning new skills is encouraged by everyone in the team.
-
Be flexible
Being located in our glass discovery room which had no desks or fixed seating prepared us amply for when we moved to our new area. Whilst we migrated into working groups we were not precious about seating, moving to where it made sense. We work as a collective team aiming to get stuff done, a fixed seating chart was not essential to help us do that.
-
Keep the team focused with JIRA
Every team needs a backlog of user stories and tasks, but we wanted to keep the team focused on building and testing things. This meant that we would not put things like ‘organise meeting’, ‘or conduct user group’ in to the JIRA backlog. Whilst those tasks are important they can be brought up in stand-up, shown on our physical kanban board and discussed in other ceremonies. It’s not the most productive use of time to create a task in JIRA when you could actually be, you know, doing the task. As a result our JIRA is clear and focused with a backlog forming.
These were our ways of working during alpha and they have proven a solid foundation. As the team has grown the ways of working have remained the same and we are producing commendable results. We’ve shared them with other teams so they can learn from our experiences. Onwards to beta!
3 comments
Comment by Dave Hardy posted on
Interested in finding out more about your kanban and jira use during alpha. We didnt use jira so I'm interested in learning how it worked (or not) for you.
Comment by Jason posted on
Hi Dave, thanks for your comment. I'm happy to share more about how we used Kanban and Jira - I'll get in touch with you offline.
Jason.
Comment by Gary posted on
Hi. Thank you for sharing your experience with everyone.
I am interested in the service itself as we have a number of services in the NHS which require means testing of income. We are also working with DWP Universal credits for prescription exemption checking. May be another opportunity to make things better for the public through cross government collaboration.