A recent conversation with a client highlighted just how hard it can be to get Agile right. It went something like this:
Client: “So we have a slightly complex setup.”
Answer: “Well in 18 years we’ve seen some fairly complex set ups, can you tell me more about it?. “
Client: “We are delivering a single platform…”
Answer: “OK, great!”
Client: “... using 5 different delivery partners, all of whom are developing, testing and releasing code, based across 4 countries, 3 continents and multiple timezones. Oh, and the timescales and scope are pretty much non-negotiable.”
Agile is easy to get wrong. Shaping an agreed working process is critical, and can be challenging. As a Scrum Master I’ve always been an advocate of ‘co-location’. Indeed (much to the derision of my colleagues), I’m a firm believer of ‘putting love in the room’. Cheesy? Yes. Valuable? Absolutely. As one of our core company values this reflects the ethos of team, collaboration, shared goals and a commitment to success - most importantly during challenging periods. The key question we were faced with in this scenario was; ‘How do you best work in an Agile manner if you’re thousands of miles apart?’
The benefit of working in such a complex environment has been the opportunity to revisit and challenge how we do things. The purpose of this, the first of two blogs, is to offer insight into working with distributed Agile teams.
Firstly, define who does what, where, when, and stick to it.
Unless it doesn’t work. Then change it. Implementing, testing and refining working processes has to be a priority from day one.
Roles and responsibilities are critical. Every member of the team should understand how they, and the team, function. The aspiration is to become ‘self organising’, however in distributed teams, this is a challenge. There is a danger that scrum sessions become talking shops, which can lead to disengagement from team members. Agile ceremonies with a strict commitment to driving value can help overcome this issue.
Team members should be there because they’re either inputting, or they’re adding value. On our recent project we determined ‘success outputs’ to all sessions. Often this meant kicking sessions off with an ‘exam question’. What are we looking to achieve?
Team sessions are intended to improve efficiency, both in the execution of and planning for sprints. To expedite this, we got creative with our ceremonies, supplementing the ‘standard’ ceremonies with ‘story time’ sessions, developed by our Agile Coach, Amy Thompson. Using this methodology has been proven to deliver improvements in the efficiencies of Scrum Teams.
Story Time sessions
Amy worked closely with Answer to introduce three Story Time sessions, PO Story time, Tech Team Story time and Scrum team story time.
1. Product Owner (PO) Story Time is a pre-sprint planning forum in which the POs of the different scrum teams share sprint candidate stories, in order to ensure we’re delivering the right level of quality and consistency across the teams. Equally, it’s the forum in which the POs finalise the next priority stories to be worked through with the teams, ensuring there is no duplication of effort.
2. Tech Team Story Time is an open invite session in which architects, developers and testers review the technical backlog, with a view to identifying candidates for forthcoming sprints the session. The technical backlog is not directly associated with specific user stories, focusing more on technical debt, and opportunities for system maintenance and enhancements.
3. Scrum Team Story Time, held prior to sprint planning, is the POs’ opportunity to walk the team through upcoming stories, from a functional perspective. The team is encouraged to discuss and challenge in order to ensure ambiguities in context and acceptance criteria are resolved. In the event further clarification is required, the team can elect to withdraw the story as being eligible for delivery in the next sprint.
So, why did we introduce these sessions? We recognised that in order to run efficient sprint planning sessions, all candidate stories needed to be ‘sprint ready’, in so much as the team have had sight of them, and had the opportunity to discuss and understand them functionally and technically. Not only did this deliver improvements to sprint planning, the throughput in sprint was improved. The sessions might have added an overhead of meeting time, but the clarity they delivered was proven essential.
Find the right way to break ‘stories’ down.
Work breakdown is key to successful delivery in Agile environments, driving development process, team behaviours and sprint flow.
In our distributed environment it quickly became clear members of the development teams had become siloed into ‘front end’ and ‘back end’ developers. The result? Functional user stories were replaced with front end and back end tasks, associated with stories. Developers were only picking up development tasks aligned to their skill set. Our challenge therefore became to encourage a change in behaviour, to push developers to become ‘T-Shaped’. Encouraging developers who ‘specialise’ in back end development, to pick up front end tasks, even to pick up testing tasks.
We referred to this transition as moving from ‘horizontal slicing’ where a broad user story is broken into disconnected front end and back end tasks, to ‘vertical slicing’ where user stories are broken down into a lower level of granularity, and are composite functional deliverables.
Our intention was simple, we had to refocus the efforts of the team to delivering working software. To drive the lean philosophy of ‘Stop Starting, Start Finishing’, and reduce the amount of ‘carryover’ which had been prevalent in earlier development phases.
In working with Agile teams, both co-located and distributed, one mnemonic I repeatedly return to when discussing the breakdown of user stories is ‘INVEST’. Simple in it’s approach it challenges the story author to continue to break a functional requirement down to become an independent, negotiable, valuable, estimable, simple, testable deliverable.
The story forms the input, the output is working software, to a ‘done’ state. Which is exactly where the second part of this blog will pick up.
In addition to defining and committing to ‘done’, I’ll also consider the importance of ‘getting tooled up’ (in the right way), and reflecting on how good it is to talk!
If you enjoyed this you might enjoy reading about our work in UX design and evaluative research.