Agile – how to document a "proper" handover

Thursday 12 July, 2018

Image by Andrew Newbury

How you leave tells you something about a person, about their passion and about what’s important to them. It can be a simple act like pushing your chair in after a meeting, pushing all the chairs in, cleaning the whiteboards even if you didn’t use them, leaving something in a better state than you found it. Below is the text of my handover notes published on Confluence ten days before our team was disbanded.

This note describes activities that Andrew Newbury undertakes in the role of PNI One Iteration Manager at NBN, it also contains thoughts and the application of key Agile principles and how these have been implemented within the team.
Most importantly JIRA is your friend, Confluence too, email isn’t.

Sprint Grooming
This happens mid sprint, exactly half way through a ten day sprint. The goal of sprint grooming is to ensure that stories are in a decent state, that they meet the published definition of ready. The entire team needs to be at sprint grooming. Why? Because the entire team will deliver the sprint. Be transparent, develop ownership. You can’t have ownership if a select few team members are in the know and some are in the dark.
During sprint grooming use Trello to develop the sprint scope. Ideally you should be using the output from the most recent Program Iteration. Sure the scope may change but what’s the point of doing Program Iteration planning if the sprint scope changes significantly? This is a difficult issue in that we need to be able to adapt to planned change, notice how I said “planned change”. Change is a constant. Constant change often isn’t planned. Planned change allows the team to prepare the stories (acceptance criteria, description, proposed release date, sizing etc) in advance to ensure that they are in the best possible state to be worked on at sprint commencement.
If a story isn’t ready at Sprint grooming then there are five working days to ensure that it is ready.
Similar to sprint planning unique pages record each grooming event including attendees and absentees, the scope items to be groomed, a real time JIRA status for these items, actions with accountable parties for completing these actions, photos of any whiteboard material generated during the events and an attendance register.
All sprint grooming has been documented here <link removed>

Sprint Planning
PNI One’s sprint planning is to ensure that there is sufficient work to be completed in the sprint. That it’s been prioritised with each story given a numerical value as to its relative importance to our Product Owner. How about “overflow” or incomplete work from the previous sprint? It doesn’t automatically become priority one. The mechanics of Sprint Planning are documented and known by the entire team typically it works like this:

  • The team capacity is known, taking into account planned leave and any public holidays;
  • Groomed stories are presented;
  • These stories are reviewed to ensure that they meet the definition of ready
    • Sized in modified Fibonacci story points (1, 2, 3 or 5), nothing over five points should be accepted, ideally smaller stories are better – small increments of functionality that can be delivered independently
    • The story is independent (per INVEST principles)
    • The story title commences with the name of the tool or service then a decent description in simple terms
    • A decent description in terms of “As a …, I need …, So that ….”
    • The acceptance criteria are clear and unambiguous eg. “Given …, When …, Then …“, this is critical. How do we know when we’ve won? How do we know when the story is complete?
    • Non-functional requirements are reviewed to see if they need updating or to be agreed to including performance, security and or scalability
    • The business owner is identified and documented on both the story and the relevant epic, this will be the go to person if questions arise, this is the person who “owns” this story from the business
    • User Acceptance Testers are identified and made aware that in a maximum of two weeks’ time this story will be ready for UAT, they are pre-prepared and ready to undertake UAT to ensure that continuous flow isn’t broken
    • The release plan has been agreed and documented for this story
    • Any special system requirements have been identified that are required to complete this story eg. special data created, extra system test environments etc.
    • JIRA tags have been correctly set and updated (these tags are often used to note if the story was new to the sprint or Program Increment – to track change over a PI)
  • Stories are sequenced in terms of value to the business, per the 1986 film Highlander directed by Russell Mulcahy with its tagline, “In the end, there can be only one“. This means that there is only one number one priority and all stories have a unique sequenced number. This assists with ensuring that given a blocker during sprint execution that the next most important item is worked in terms of business value;
  • The NBN System Team have been using SonarQube for code quality analysis and steadily applying more restrictive rules, given the situation where the planned release date is some time after the sprint then at code merge time there may be code quality issues which need to be factored into the story size;
  • The team have agreed to create “test data requirements” for Monthly releases (MR), for any stories where there are Monthly releases, time will need to be added to the sprint to create these test data requirements; and
  • As NBN moves further towards DevOps the Functional Integration Environment (FIT) will begin to be used as a precursor to the MR environments, this will initially be for functional testing and as such the team may need to create test data, perform testing in this environment and coordinate with other teams.

If a story doesn’t meet the documented definition of ready then it goes into the backlog and is excluded from the sprint and the next most valuable item is taken from the backlog or the next sprint and added to the sprint scope.
The status for the current sprint is located here <link removed> and the JIRA sprint numbers updated when a new sprint starts. This shows the time elapsed, work completed, scope change and burn down charts plus real time JIRA scope status by assignee and story status plus a list of all stories from JIRA.
During sprint planning I copy the previous sprint plan page and customise it for the current sprint. I send out a link to this after sprint planning has concluded. Each page documents who attended the event and notes any absentees. A photo of the confirmed scope from the whiteboard constructed as input to print planning, the JIRA scope in real time, photos of any whiteboards, the sprint goal and a link to the attendance register.
All sprint planning has been documented here <link removed>

Sprint Showcase
The aim of a sprint showcase is to get early feedback (per the Deming inspect/adapt loop) through showing the business stakeholders want’s been completed in the current sprint. As a team we’ve tried a number of different ways of showcasing our work from having the technical lead present through to the developer who worked on the item. The most successful showcase was for sprint 23 where we focussed on “what’s in it for me”. We looked at our work for a business perspective in terms of what the work we’d completed would mean for them rather than looking inwards at the work we’d done from a technology perspective. Planning is everything here. We met a few days before hand and built a plan of how we were going to present – which is often more important that what you’ll present. Our planning agenda was:

Focus: showcase

  • What will we showcase?
  • How will we showcase it?

Showcase Agenda

  1. Sprint goal
  2. Sprint summary
    a. What we did
    b. What we didn’t do (and why)
  3. Sprint demo – demo all work completed
  4. Blockers and risks found during the sprint
  5. Velocity review – what our velocity was and why
  6. Preview of next sprint
    a. Focus area for next sprint
  7. Planned releases
    a. What epics we’ll be completing and when

All showcases have been documented here <link removed>

Sprint Retrospective
As a team we’ve varied the retrospectives from semi structured conversations around what went well, what could have been improved etc through to more formalised activities from http://www.funretrospectives.com. Typically and as per the Scrum framework we’ve as a team selected at least one improvement item per sprint and allocated tome to this activity to ensure that it gets done.
All retrospectives have been documented here <link removed>

Visual Management Board
As a team we came up with the new look design for our Kanban board. Each team member takes it in turns at the daily stand-up to review what they’d done in the last working day to advance the sprint goal, what they’ll do and if they’ve found any blockers. They mark the relevant story card the day after they’ve done work on that story – to assist with ensuring that no cards are ‘unloved’. If a team member is working on a card then their photo is added, or removed if they’re not working on one. The Iteration Manager takes part too.
Issues that we’ve encountered are around releases not going ahead for a particular tool, often because a dependent application (from a different team) wasn’t able to be completed per plan and this has led to a number of issues around flow. Typically stories that have stalled for some time require code refactoring to take account of code quality rules which have been implemented by the PNI System Team afterwards. This leads to rework and inefficiency. “Clubbing” stories together leads to unrealised value and decreases flow.

Confluence
We’re reliant on Confluence as our source of truth and as a transparent repository of team processes, releases, plans and activities. The main sections are self-explanatory:

  1. Team – photos and contact details, definitions eg. Done, ready etc, educational material, ‘having fun’ aka team events etc, processes, reports, retros, SAFe team self-assessments, team calendar (leave etc)
  2. Plan – photos of the Kanban board (primarily when our nine product owners were interstate), Monthly Release containing the agreed scope and a JIRA query to confirm the scope plus all MR status report, actions and meeting minutes, PI planning and status including retrospectives from PIs.<link removed> is a special location which uses dynamic JIRA queries to show real-time status of the PI across epics and stories with their status and percentages, scope change (epics and stories added) managed by the use of JIRA tags like PI4-Unplanned for work which came into the PI after PI planning had completed, automated testing to capture our uptake of automated tests, epics by due date to show what’s being delivered when and then a great section on software bug analysis with reporters, assignees and defect types (a great source to ensure that we’re targeting specific defects). Grooming and planning also live here under “Plan”.
  3. Design – the team’s ITIL like service catalogue and non-functional requirements repository. This is the source of truth for PNI One tools with the official names that we use for our tools & services (we had many instances in the past where services had slightly different names in JIRA and elsewhere), links to the design documents, NFRs and component catalogue IDs. I contacted Release management to link this page through to the official NBN Service Catalogue and was told that no such thing exists.
  4. Build – needs far more content.
  5. Test – mainly MR test plans and notes on software quality
  6. Release – main repository for all release activity including: ASM transition, BAU & HotFix releases, Release Audit Pages (which use specialised JIRA tagging to show release branches, released and planned for release stories, stories which have been merged to SIT or a BAU branch, transition signed off, UAT/SIT sign off etc). Root cause Analysis – for any production release which fixes an issue it is mandatory tat before I’ll approve a code merge that the details have been captured: defect, defect cause, defect fix. There is also a flow chart here describing the process which the team follows upon a production incident being raised. Sprint demo/showcases live here too plus a stakeholder communication template for releases.
  7. FAQ – any time the team provides a skills transfer to another team the questions asked and answers are documented here. This is to ensure that knowledge is captured and readily available for reuse.
  • Index – an index of all content on the team site, useful for finding material
  • Searching & Table of Contents – a search capability just for this team site, not NBN Confluence wide. Plus a complete list of all pages on the site in their hierarchy.

Attendance Register
I’ve taken a register during all sprint grooming and planning events to note down who attended, typically we’ve been underrepresented by solution architecture but well represented by our product Owner and Business Analyst.

Leave Tracker
Is updated on as needs basis and the team knows that planned leave needs to be documented here as early as possible to ensure that we have an accurate grip on future team capacity across sprints.

JIRA
Use JIRA to document anything and everything unique to a story or epic. If team members have a conversation about a JIRA story or epic or an email chain contains valuable information make it the responsibility of the initiator to document the conversation/material in JIRA. Why? It’s the source of truth. We shouldn’t have to rely on memory, it needs to be captured and documented so that those who come after us will know how we’ve arrived at the decisions that we have made. I often joke with the team that this is in case we lose someone (run over by a bus), that their knowledge isn’t lost since it exists in our primary repositories of JIRA and or Confluence as appropriate.

Email
Dissuade team members and stakeholders from using email. Instead have face to face conversations then document these in Confluence or JIRA as appropriate. Long email chains are inefficient. Agile Principle #6 (which the team can quote to you) is “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Seriously, don’t use email. If you have to make an announcement, do it via email but with a link to the announcement. Why? The three pillars of Scrum (an Agile framework) are

  • Adaption
  • Inspection; and
  • Transparency.

SAFe‘s core values (also an Agile framework) are

  • built-in quality
  • alignment;
  • program execution; and
  • transparency

So how does transparency as a concept align to email? Email is great if you’re on the email chain, if not then you miss out. Documenting material in JIRA and or Confluence ensures that we have 100% transparency. Documenting something in email only works for those who are a recipient. Email negates transparency. Per my email footer
Our primary method of communication is face to face, followed by Jira and Confluence, email is not preferred.
Avoid email. Enough said.

Meetings
PNI One knows that if there’s no agenda then they don’t need to attend the meeting. If there are no minutes with assigned actions then it’s simply a conversation and future meetings are then optional to attend. From the Agile Principle #1 “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” This means that anything that does not directly relate to advancing the goal of valuable software delivery isn’t a priority. Meetings without a published agenda mean that you can’t prepare and may be of value to the organiser but not to the rest of the participants. Work out how much time was spent in a meeting: for a one hour meeting with four participants (including the organiser), that’s half a working day (lost) in person time. Is the meeting really critical? Does it advance Agile Principle #1? Ensure that the team are allowed to decline meetings without agendas, doubly so too for meetings called without sufficient lead time and or called at a time when invitees are already have calendar commitments.

MR and Release Activities
These have been problematic in the past specifically in that the scope changes so frequently and code needs to be ready months ahead of the actual release date. I had appointed a release lead wanting the activities to be better documented and repeatable. This didn’t happen so I created pages specifically for each MR so that we knew the agreed scope, the real time scope (which acts as a check to see what’s changed over time), copies of all meeting minutes and MR status reports and kick off packs (no email!!). This allows anyone who wants to know the status of a PNI MR to simply look for themselves. Self-service enablement. Waterfall release doesn’t gel well with an Agile development team though and we’ve hit many issues where other teams have pulled out of an MR causing PNI One to have to pull out too. Then sometimes months can go by before the other team is ready. During that time our code gets stale. Memories fade and new code quality rules are created. This leads to lost value. Done isn’t done until our customer can use our work. Partially done work is a scourge.
Monthly Release material is here <link removed>

Definition of Ready
I started with a slightly lose DoR and have tightened it over time, especially the maximum story point size. Where this was once up to forty points it’s now a maximum of five. I’ve never rejected a story but have actively stated many times that if a story doesn’t meet DoR at sprint commencement then it will be rejected.
The DoR lives here <link removed>

Definition of Done
Basically unchanged from when I took on the role of IM. Why? We have waterfall release. We don’t have intraday release processes. Done is still when development has completed and UAT is able to commence. I would have tightened this over time. The new functional integration testing environment will help and once this is working I would extend done to include completion of FIT testing.
The DoD lives here <link removed>
What else? It’s an awesome team which has come to enjoy taking ownership of their own work as a team. They’re self-empowered, they can do anything they need to knowing that their IM has their back. They enjoy the freedom of making decisions as a team, they pull work rather than have it pushed to them, they’ve cross skilled and taken on roles outside their comfort zone. They understand where their widgets fit into the business process and aren’t kept in the dark.