Implementing the basics: WA, DoR & DoD

Implementing the basics: Working Agreement, Definition of Ready and Definition of Done

At giffgaff, I’m an Agile Scientist – we call ourselves Agile Scientists because we aren’t just Scrum Masters, we’re coaches, mentors, friends, leaders (servant and behavioural, aka leading by example) and, importantly to the noun, experimenters. As many of you may know (and many may not), a key to agile is constantly experimenting and if there’s one word I could use to describe giffgaff it would be experimental.

My role isn’t just about following/owning a process or facilitating ceremonies (although that is included), it’s also about understanding people, being able to work with psychology and also experimenting with new things to find a more efficient way to work. By new, I mean both tried-and-tested activities and also playing around with the unknown. 

Writing about implementing a Working Agreement (WA), Definition of Ready (DoR) and Definition of Done (DoD) may strike some people as un-experimental. “They’re basics of Scrum” I hear you say or “everyone has those!” Well, no, they don’t. I’ve worked in a number of agile teams across various industries (tech, telco and banking) and I can firmly say that these “basics” are not executed across the board. The reasons are many, from the “our team doesn’t need it written down” to “that’s just not done here” aka, office politics, or “they’re not that important.” I can hear the cackles of some of you now… 

One of the teams I work with has been together for about a year, working in a start-up environment within giffgaff (check out giffgaff gameplan btw, it’s awesome!). Due to various reasons, while working Scrum they’ve never set-up any of the three artefacts under discussion. It was noticed that sprint after sprint there was at least one if not more stories not being completed within the timebox. On the surface, the reasons were “we’re waiting on the third party” or “it was more complex that we thought.” Digging into it, the real reasons were that stories were being brought into sprint when they weren’t ready. Why? Because the team didn’t know what ready meant. The stories were delayed completing, why? Because sometimes ‘done’ meant before QA and sometimes it was after. When asking about what their DoR and DoD are I got blank looks in return. I took this one step further and asked about their Working Agreement, again – blank looks. 

After a brief explanation of what the artefacts are, the team agreed that we should take a shot at putting them together and trying them out. The WA took a little longer than planned to pull together because the concept was totally new to the team. The conversation was brilliant, it was open, honest and built a fantastic social contract that we’re all onboard with. The relationship amongst the team has always been good, and you can tell that providing a platform to voice these behaviours has had an even more positive affect. For example, “we are always open to questions” came about because a member was nervous of interrupting others while they were coding, but the others weren’t aware. A little thing like this helps to make the teams feel more comfortable in their environment which in turn encourages empowerment. 

Strictly speaking, you don’t have to have a Working Agreement as part of your Agile or Scrum team, however it is a very useful tool to encourage the right behaviours within a team; discussed and agreed together, the WA not only encourages the desired behaviour of the team but also provides the empowerment and confidence to hold each other accountable. Feeling empowered to hold ourselves and each other accountable to our agreements is essential to a productive environment and high performing team. Being empowered means we have the courage to speak up when we have questions to ask or when we need to raise pressing matters. Being empowered also means we take ownership and we encourage those around us, too. 

The team will openly admit that they weren’t too keen on having a Scrum Master (Agile Scientist!) at first because “we’re fine!” 8 weeks later and the feedback is nothing but positive and there’s more discussion of what to do next. The tools, processes and techniques that my role brings, such as small changes like adding structure and applying simple practices can, and are having, a huge impact. 

I have attached copies of our WA, DoR and DoD so you can see for yourself. Of course, they’re not perfect and they’re not meant to be. They are written in context for the team – if you have any questions around any points then feel free to comment/message to find out more. Or if you have any suggestions then we’re all ears for further improvements.

The moral of the story, and one of our wall quotes: Old ways don’t open new doors ??