team processes – Carina Silfverduk

A team I have been working with recently has reached a milestone. When I first started working with this team, most work would get to “development complete” but would linger in QA for multiple sprints or would not pass Product Owner approval so the work never got to “done.”

This particular team had experienced a lot of turnover and strife. I don’t know all of the details, but I can say that even just having people move in and out of a team can create enough instability to make holding to the team’s Definition of Done (DoD) difficult.

I think most people on the team understood what their Definition of Done was, even if it wasn’t something they said out loud or had written on the wall somewhere (but you can do such an activity in a retrospective, and I highly recommend it).

This team was writing automated tests, code reviewing check-ins, ensuring new work passed the test suite and built successfully. Everyone seemed to understand in concept that QA had to test their work and bless it, and ultimately the work needed Product Owner approval, but that’s not what was being measured.

The act of measuring something impacts your results. People naturally start to key on what you measure. This team was being measured on how much work they could get to development complete when I first started working with them. I knew instantly we needed to adjust it, but getting to shift the team towards the right measurements couldn’t happen overnight. I needed to better understand why this was happening, and then determine what to do to move towards what should be happening.

For any Agile team, the Definition of Done (DoD) is very important. It becomes how you know you’ve met your sprint goals and commitments and it gives a guideline for what the team considers to be completed work. It’s also how you measure the team and the work at a high level, for sprint planning purposes and at retrospective time to understand what trends the team experiences and why.

Every team’s DoD may differ, but generally, done does not mean “development complete.” It’s rare to be development complete and have fully releasable software on the first try. When development work is passed on for testing and quality checks, there are inevitably bugs/defects to fix or improvements to be made in the work. The Product Owner or Stakeholder may request tweaks or changes before approving the work, or alternately may accept this iteration’s pass at functionality while requesting tweaks in the next iteration.

Done usually means the work in question has met a level of quality the team has agreed on. Quality Assurance, Business Analysts and Product Owner(s)/Stakeholder(s) have approved the work. Acceptance criteria are met, and automated testing and/or checks (performance/load etc) have passed.

Generally, done for Agile teams should mean the work is releasable. Releasable, but not necessarily released. Meaning if you were to stop work after a given sprint, the product you have developed so far would be able to be pushed live and provide value. Some teams release small improvements often. Some teams group development work into releases containing multiple sprints worth of work. Regardless when you release, at sprint end, your work is ready for real world use.

Definition of Done can be skewed when there are things happening that [someone or the team] is trying to address- for example none of the work involved in getting to QA or Pending Product Owner Approval counts as completed (in terms of moving up the field). If you have enough work that lingers like that just shy of done that leaves a team demotivated because no one acknowledges their hard work. Or someone isn’t addressing the concerns coming from the Quality Analyst or Product Owner. Or someone isn’t protecting the process. This is a process problem AND a people problem. Sometimes it’s people not understanding the process. Sometimes it’s absence of process.

On teams where work is frequently not meeting the definition of done, Scrum Masters / Agile Coaches must be looking at why and working together with the team to find solutions.

Your very first step when encountering a team that isn’t performing the way you think it should, is to start looking at what’s going on with an open mind. Find out what they consider as their DoD – either formally, through a retrospective, or informally, through observation and casual discussion.

Observe. Take notes. If possible, talk to the team about what you are seeing. Inevitably, there are reasons why the team is where they are, and as in the Retrospective Prime Directive- that’s a result of everyone’s actions and inaction – they were doing the best they could at the time. No need to start blaming anyone. Just start addressing the problem in a constructive and adaptive way.

Ask questions to discover what may be preventing the team from getting to done.

Is the definition of done too difficult to meet? Too ambiguous?
Is the team spending enough time discussing the work and how to approach it in sprint planning?
Are stories fully defined or do various roles have to track down information during what should be development or testing time?
Are acceptance criteria too ambiguous, resulting in confusion over whether the work is complete, or whether the work passes the expectations of it.
Does the stakeholder/product owner understand incremental software development and accept working software (a few most valuable features that work well rather than pressing to get all of the features that barely function)?
Does the team have all of the skills and experience needed to complete work? Does the team have the right balance of skills?
Is there a workflow problem? Are the right people involved at the right agile ceremonies to keep work moving (especially review of defects and work failing testing as well as product demo and stakeholder approval).
Is the team overloading the sprint?
Where does the work tend to get stuck, and why?
Are team members remaining blocked without hope of help getting unblocked?
Does the team fully grasp the agile sprint lifecycle?
Is someone protecting the agile process?

This is just an example list. Remember, look at what’s going on with an open mind. After asking questions, start looking for solutions. It’s easy to complain, but it’s much harder to take problems and start finding solutions. It may help to use a Retrospective Method such as Known Issues, AFTER clarifying the Definition of Done (DoD), to collaborate as a team in finding ways to solve the problem for the team.

As an example, for one team I worked with not too long ago, we identified one main reason they didn’t reach DoD was the work was not fully defined. People doing the development had to spend time tracking down and clarifying with Stakeholders what was desired. People testing the work had to spend time walking through with the developers what the heck the software was supposed to be doing. Stakeholders didn’t understand that the work could be further improved in a future sprint and didn’t want to release before everything was perfect. All of these things left work just shy of done at the end of the sprint.

When problem solving how to address the DoD issue with this team, there was one root cause and 3 resulting problems to consider. The first thing they decided was they wanted to write more robust acceptance criteria. The second, that they would not begin work without clear acceptance criteria and they would consult these acceptance criteria in determining whether the work was complete. The third was that QA would use this criteria to evaluate the work. And lastly, they had to, over time, help their Stakeholders become more comfortable with the idea that the software was ever evolving and improving.

Every team is different but getting to done is the general goal of an agile team during the sprint. If your team is struggling with this, it’s time to examine why.

From 2008 to 2010, I had the unique experience of working overseas in Sweden. It was a fantastic opportunity, and I learned a lot about how cultural norms can differ. Workplace norms are not the same everywhere in the world – and this was surprising to me.

I had assumed that working in IT would be nearly the same. Programming in Sweden was very similar to programming in USA- all of the programs were in a language I knew (English), and the technologies I used were familiar. My keyboard had some extra keys on it, and surprisingly, this threw me off for the first month or so. I kept accidentally pressing the wrong keys, and that led to slower coding.

The cultures in the various offices I worked in were vastly different. From the moment I entered my first interview, this was clear. Instead of focusing on my career highlights and my strengths and weaknesses, hiring managers wanted to know was I fully rounded individual? What did I like to do in my spare time?

The norm in USA of talking up your experience and skills was not acceptable in the humble company of Swedes either. This might have been the hardest adjustment for me. To me, finding a job and standing out against other candidates meant aggressively selling what I could do. To the Swedes, this seemed like the boasts of someone who liked themselves a little too much. I had never looked at myself as being someone who was full of themselves, but to survive in Sweden’s job market, I needed to tone it down.

Another thing that struck me, again and again, was the power of shared expectations. In Sweden you were expected to follow certain cultural norms, and everyone I met did things to help you know what was expected of you. On the bus, someone would helpfully remind a gentleman to give up his seat for the elderly, or else every occupant would turn an angry eye to the man who did not give up his seat for an elderly woman. That peer pressure was powerful.

People said what they meant. If a friend said let’s get coffee, they actually meant it. We better be getting coffee!

In one office, we had coffee break or fika, every day in the mid afternoon. I can verge on workaholism, so my teammates would subtly stop by my desk just before to encourage my attendance.

Even living in Sweden, the government encourages you to understand the country and fit in. I am a Swedish citizen, but I was not fluent enough in Swedish and was encouraged to attend a free class to learn the language and culture better. For this small nation, gentle cultural guidance helped those not used to the expectations to fit in.

In the same way, Agile teams can use their defined cultural norms to help new members onboard, and to encourage each other to be better team members. This can be done in many ways, but the retrospective is one of my go-tos.

I may not have posted about this here yet, but in my daily life, I say all the time that one should vary retrospective methods. It is truly the most powerful tool in the scrum master’s toolbox, and using the same method every time is like using a hammer for every job around the house. You might get some things nailed in, but you’re likely to get some dented walls and fixtures too.

One method I like using in retrospectives with new teams, or with teams in which it seems like discord appears to be growing, is to define our team’s working relationships with “That Guy, This Guy.”

With this method, after reminding the team about the Retrospective Prime Directive, the team works to define the kind of team member that is difficult to work with (Don’t Be That Guy) and the kind of team member they love to work with (This Guy Rocks!).

I did this retro with a team I worked with in the last year. The That Guy, This Guy artifact became their playbook for their team. Take a look at some of the qualities that That Guy has versus This Guy.

“That Guy” passes the buck, isn’t accountable and closes new ideas down. The phrase, Don’t Be That Guy takes on special meaning when we define the behaviors that make it hard to work with someone.

On the other hand, look at the qualities this team defined for the sort of person everyone enjoys working with – proactive, helpful, and willing to pitch in. Everyone wants to work with “This Guy.”

Agile is all about raising accountability for all team members and pushing the team, and the individuals in it, to be their best selves. As human beings we like examples of what that means. For each team, this may look a little different. It depends on your business, the products you work with, and your processes.

A similar retrospective method I’ve used is called Ground Rules, which is especially appropriate to use in the formation of a new team. The premise is similar – how do we work together best – what rules do we agree on and what new ones should we consider? These rules then can be passed on to any new team member to give an example of how the team expects members to behave.

In summary, these retrospective methods really boil down to the team defining how not to be a jerk. They arm the team with a way of calling out what their preferred behaviors are, and a playful way of saying, hey- This Guy Rocks!

This is super important in agile teams where the team dynamic has more potential than ever to slow down productivity if people don’t play by the rules, or conversely, produce more than ever as the team gets better at working together.