Ways of working

1. The TIS team began Agile working using the Scrum framework.
2. We then transitioned to LeSS (Large Scaled Scrum).
3. We are currently experimenting with a combination of Scrum and Kanban (loosely referred to as Scrumban - though this is not a formalised Agile framework).

As an Agile team, we regularly review our working practices in line with the work we have, the team we have, and what we feel is most appropriate at any time.

"Scrumban"

Kanban daily working, but using the Scrum iteration and ceremonies. This approach is often used when the stakeholders in the organisation are broad, plentiful and have got used to the Scrum cadence.

Kanban

A "pull" model as opposed to the Scrum "push" model.

That is to say team members pull a ticket from one state to the next at the point that they start work on it in that new state.

In Scrum, once you've completed working on a ticket in a particular state, you push it to the next and either you or a colleague then picks it up and continues working on it.

Kanban does not have iterations, and is a continuous flow of work. As a result the focus for a Kanban team is reduction in waste - specifically lead times (time between initially raising the issue and starting work on it) and cycle times (speed of throughput once the work has been started). This is handled by breaking down the 'In progress' steps so any bottlenecks become transparent, and introducing WIP limits on each column - forcing the team to collaborate on, and finish, at least one of a small number of tickets 'In progress' before starting new work.

LeSS

Scrum, but for several teams who align their ceremonies

• 1st Planning session is to divvy up the work and tag them to each team, 2nd Planning session is for each team to commit to a proportion of those tagged tickets.
• Staggered daily stand ups.
• Staggered Refinement sessions.
• Joint Team Sharing sessions.
• Combined Review.
• Staggered Retrospectives.
• Overall Retrospective - to pool best practice from across the teams, and to highlight common issues.

Scrum

3 roles

• Product Owner: management of the backlog. Final arbiter of Priority of work.
• Scrum Master: coordination of the team. 'Servant leader' protecting the Dev team from external distractions / influences and removing blockers from their path.
• The development team: self-organises to deliver a potentially shippable product increment at the end of each Sprint.

5 event

• The Sprint: 1-4 week period for the team to timebox development of deployable work - in the TIS team we follow a 2 week Sprint pattern.
• Sprint Planning: meeting for the team to commit to work.
• Daily scrum (stand up): 15 min synchronisation meeting for the team to share progress, ask for help, highlight impediments and highlight where collaboration between specific team members would be beneficial. A 24-hour inspect and adapt meeting. We carry this out next to the Wall (a physical visual representation of what's in Jira - useful for two reasons: not everyone engages with Jira, or does so in the same way, so some things remain somewhat 'hidden' for team members in Jira; Product stakeholders often can't access Jira, but are still interested in Sprint progress.
• Sprint Review: meeting to inspect the work ‘Done’ during the Sprint with stakeholders with the desire to get their feedback on it, and their steer on future product direction. Also to understand reasons for work not getting 'Done' - this highlights blockers that need dealing with and mitigated against in future.
• Sprint Retrospective: meeting for the team to introspect and adapt their ways of working in order to make future Sprints more effective, and improve team working.

3 artifacts

• Product backlog: everything currently known that the team might eventually work on.
• Sprint backlog: everything the team will work on in the next 2 (in our case) weeks.
• Increment: a potentially shippable product increment – “a body of inspectable, 'Done' work that supports empiricism at the end of the Sprint”.

Roadmap

We are currently working on developing a Product roadmap - a forward looking indication of what the team will need to work on. This should avoid dates and commitments, but where anything does have a real known deadline, this should be indicated. That way, the team can then determine interrelationships between work and dependencies.

Components

The Product was split into Components in the lead up to going 'live'. Since this point, we have re-worked Components to be more user focused and revolving around the typical user journey, rather than the structure of the App.

Product Backlog

Under each Component, the Product Backlog is split into LiveDefects, Support, Bugs, Stories and Epics.

• LiveDefects are tickets for work needing to be carried out immediately as a result of a Production environment incident preventing normal use of one or more of our services
• Support are tickets for hand-holding we necessarily do as part of ensuring our services are fit for purpose - especially when we release some new element
• Bugs are defects raised by anyone against one or more of the Production environments. They are either defects that our test coverage missed, or specific defects in the way that the code functions that were not covered in the original Stories for developing that code (so could not have been tested).
• Stories are discreet independent pieces of work that provide value to the customer. They may be large or small, but should always be sized in such a way that they can be completed within a single iteration.
• Epics are large pieces of work normally encompassing several Stories. They are too large to be worked on in an iteration, as it would not be possible for the team to complete them within a single iteration. And often they are more broad areas of work, that take many multiple iterations to complete

Ready for Development

This column on the Kanban board necessitates a level of detail having been added to the tickets:

• LiveDefect detail: description of the problem, with a link to the incident log. Focus with LiveDefects is to resolve the immediate problem and create follow-up tickets to mitigate the error recurring (Note: in the middle of a LiveDefect, it is often relatively easy to also refine the follow-up tickets - while the knowledge is fresh).
• Support detail: description of the support required, and possibly a follow up ticket to enable service users to use the service intuitively without having to raise that support request again.
• Bug detail: a description of the problem; steps to reproduce the problem; details on OS / browser used if relevant; screenshots to help clarify the problem and enable the Dev team to reproduce it. An indication Value is also useful to describe. As is a description of the complexity of the work.
• Story detail: requires a User Story (why is something needed, what it is and who is it for?), Acceptance Criteria (how to test that the Story is 'Done': using a Behavioural Driven Development approach - Given the current state of the system, when the Story is completed, then the result is observable). It also requires an indication of Value and complexity.